When a new media type is registered, that registration gets to define
what a fragment identifier means.
While RFC 2396 says:
The semantics of a fragment identifier is a property of the data
resulting from a retrieval action, regardless of the type of URI used
in the reference. Therefore, the format and interpretation of
fragment identifiers is dependent on the media type [RFC2046] of the
retrieval result.
we didn't include an "IANA considerations" section that required
the addition of a "Fragment Identifier definition" for MIME
media types, or a retrospective definition for any other
media type.
In retrospect, this was an oversight, but it's correctable.
We would want to extend the media type registration form of
RFC 2048, either through an 'additional information' suggestion
in 2.2.9 or by an explicit addition to the registration template.
If XPointer updates the interpretation of fragment identifiers
for application/xml and text/xml, it should say so explicitly,
and the revision of RFC 2376 ("XML Media Types") should update
the template used.
It's also possible to update the text/xml & text/html template
explicitly.
So, the language in the XPointer draft is clearly saying, for text/xml
and application/xml, this is the syntax. It doesn't say anything about
other media types, presumably because it can't speak for them.
Other media types can define their own fragment identifiers, which may
have very different requirements to Xlink or may have exactly the same
ones. So they might well say that they use XLink, too.
Or they might say something like "we will allow only links to a given
ID but we will use the exact same syntax XPointer uses for that, for
compatibility". In other words, all valid fragment identifiers for thast
type would use XLink, but not all possible uses of XLink would be valid
for that media type.
I agree with all of this.