[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Media types and XPointer, XLink, XPath, and XSLT

> 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

> 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.