Automatically setting the correct Content-Type for XML documents based on namespace

--=-gGXaG4Ep0Ws8JBSXNz2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,
XML is used for many different kinds of files, and Apache serving up all XM=
L files as having application/xml type unless explicitly told otherwise is =
suboptimal. For example, correct usage of more specific types can be useful=
 for content negotiation: a user agent might have a preference between 'tex=
t/vcard' and 'application/vcard+xml', for example. Just as Apache does for =
XHTML, these files usually contain enough information to identify their cor=
rect type and, when the top-level element has a designated XML namespace, t=
his can be done without any chance of error: determining a more specific me=
dia type for an XML document is then a deterministic procedure, not a matte=
r of guesswork.

I can't find any existing solutions using Apache as the HTTP server, though=
, such as with a module. Is this just something no one has gotten around to=
 implementing yet (either in the Apache HTTP Server project or on their own=
)? Has anyone solved this problem before? Here's some research I've done on=
 the matter.

 =E2=80=A2 It appears there is precedent for using libxml2 to implement fun=
ctionality in httpd, but the only obvious one is in mod_xml2enc https://htt=
pd.apache.org/docs/trunk/mod/mod_xml2enc.html which is about handling text =
encodings on-the-fly as a filter. If libxml2 is already used some for Apach=
e modules, then using it to parse an XML document's root element, namespace=
, and DOCTYPE declaration ought to be pretty straightforward, as a first st=
ep to inform the choice of a superior media type. Do any other parts of the=
 server do anything like this? If not, I'm hopeful a quality implementation=
 of this could be considered for inclusion in the core distribution.

 =E2=80=A2 To heuristically determine media types of files generally, mod_m=
ime_magic https://httpd.apache.org/docs/trunk/mod/mod_mime_magic.html is de=
scribed as working "like" the file(1) command. Unfortunately, Apache uses i=
ts own home-grown implementation for this job ("This module is derived from=
 a free version of the file(1) command for Unix"), and it expects to be use=
d with a MimeMagicFile in the format of the one supplied by Apache. This me=
ans that even when improvements are made to the file(1) command and libmagi=
c library that the majority of libre systems use, it will not trickle down =
to Apache. Is there a reason for this apparent code duplication?
Maybe it comes from a time before the libmagic library https://www.darwinsy=
s.com/file/ existed; curiously, that upstream project is the same as what m=
od_mime_magic is based on anyway.

 =E2=80=A2 This subject matter is based on the premise that the name of an =
XML document's root element, along with at least one of a document type dec=
laration or an XML namespace declaration, can uniquely identify an XML docu=
ment's kind and inform user agents of how to use those XML files fetched. T=
his can be materialized from two different approaches, neither of which I'v=
e been able to pull off.

	=E2=97=A6 The IANA has the registration of a media type called application=
/prs.implied-document+xml https://www.iana.org/assignments/media-types/appl=
ication/prs.implied-document+xml which allows this concept in general. The =
comments for the registration express this well:
> This media type identifies a meta-format that encompasses all XML-based f=
ormats which are identified by a particular name of the root element, optio=
nally together with a namespace URI or the PUBLIC identifier stored in the =
DTD. It it intended for use in applications that describe files using media=
 types, but do not have sufficient heuristics to output a more specific med=
ia type. In such a case, the application may parse XML and use the name of =
the root element and the DTD to the "root", "ns", and "public" parameters.
It even gives an example: the common image/svg+xml type is approximately eq=
uivalent to
	application/prs.implied-document+xml;root=3Dsvg;ns=3D"http://www.w3.org/20=
00/svg";public=3D"-//W3C//DTD SVG 1.1//EN"
If something somewhere in the pipeline could express a media type like this=
, then the canonical image/svg+xml could be substituted as an alias somewhe=
re.

	=E2=97=A6 An orthogonal issue is, in what way could we define such "canoni=
cal media types" that correspond to some XML document type? I am pleased to=
 discover that the shared-mime-info database specification, commonly used o=
n GNU/Linux, already provides for this! https://specifications.freedesktop.=
org/shared-mime-info/latest/ar01s02.html#id-1.3.9
As a matter of fact, on my Debian Trixie system, a file /usr/share/mime/XML=
namespaces already exists. This is a short plain text file with lines such =
as
> http://www.abisource.com/awml.dtd abiword application/x-abiword
> http://www.w3.org/1998/Math/MathML math application/mathml+xml
> http://www.w3.org/1999/xhtml html application/xhtml+xml
and so on. So regardless of whether the application/prs.implied-document+xm=
l media type is used somewhere as an internal representation, this is a str=
aightforward mapping that provides everything needed. If only Apache could =
use it.

If any solutions exist along these lines, I don't know of them yet but woul=
d love to. Otherwise, I ask of the sympathetic readership: how do you handl=
e this?

--=-gGXaG4Ep0Ws8JBSXNz2d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iPsEABYKAKMWIQSiPzylvTnZ6xisfzWz9N0oYfTNugUCagYzu3IYaHR0cHM6Ly9q
b2huc2NvdHQubWUvLndlbGwta25vd24vbmkvc2hhLTI1Ni9zWUF3OTN6QUVrRkIy
RDREM1hOemRSeHEyMFBjNnByZGdtbEVWeXo0QUZRP2N0PWFwcGxpY2F0aW9uJTJG
cGdwLWtleXMSHGpzY290dEBwb3N0ZW8ubmV0AAoJELP03Shh9M26a5EBAOTDr50T
VA/19oklPG64eaLv99NekdFhdsnoAfQtnKsNAQD5KZEnH8PPX6QBLpzd0pd+ATXo
V26w6SpgqbDu1az8Dw==
=oS8O
-----END PGP SIGNATURE-----

--=-gGXaG4Ep0Ws8JBSXNz2d--