Generic XML files are unclassified/skipped — no tree-sitter grammar or extraction path for .xml

[lebougui]

Summary

Generic .xml files are not supported by graphify at all — not as code, not as docs. They fall through as "not classified" and are silently skipped, contributing zero nodes/edges to the graph.

This is distinct from the MSBuild/.NET project extensions that are supported (.csproj, .xaml, .razor, .cshtml, .fsproj, .vbproj, .sln, .slnx) and from the pom.xml-filename special case (which extracts a Maven package + depends_on edges, not general structure). Neither covers arbitrary XML schemas used by other ecosystems (e.g. Ant build.xml, Java web.xml, or product-specific config/workflow/template XML).

Repro

$ mkdir xml-test && cd xml-test
$ cp .xml .
$ graphify extract . --no-cluster
[graphify extract] found 0 code, 0 docs, 0 papers, 0 images
[graphify extract] 1 file(s) not classified (no supported extension or shebang), skipped: .xml
[graphify extract] wrote graphify-out/graph.json — 0 nodes, 0 edges (no clustering)

Also confirmed with known build-tool XML manifests that aren't Maven:

$ graphify extract . --no-cluster # dir containing build.xml (Ant) + web.xml
[graphify extract] found 0 code, 0 docs, 0 papers, 0 images
[graphify extract] 2 file(s) not classified (no supported extension or shebang), skipped: build.xml, web.xml

Tested on graphify 0.9.48, with graphifyy[all] installed — tree_sitter_xml is not a dependency in any extra, including all.

Impact

Real-world impact: a legacy C++/XML-heavy repo we tried to graph has ~1,062 XML files (workflow/delivery/schema definitions — core business logic, not boilerplate) alongside ~1,065 C++ files. The resulting graph fully represents the C++ side but has zero representation of the XML side, with no warning that anything was skipped except a generic "not classified" note buried in the log. For a repo where XML carries real logic, this produces a graph that looks complete but is missing a structurally significant portion of the codebase.

Ask

1. Add a generic XML (or XML-family, e.g. via a shared grammar covering common dialects) tree-sitter extractor to the supported extension list, similar to how .json is handled.
2. Failing that, at minimum surface a louder warning (not just "not classified") when a large fraction of a repo's files are silently unclassified, so users don't mistake a partial graph for a complete one.

Related: #2851 (classify plugin XML / properties / Dockerfiles as deterministic CODE) is adjacent but narrower — scoped to specific known manifest filenames, not general XML parsing.