fragment identifiers and media types (was RE: XPointer considered incomprehensible)

On Tue, 2006-09-05 at 08:14 -0700, Jonathan Marsh wrote:
> AFAICT, the +xml convention does not have normative force on XPointer
> compatibility.  Each media type must therefore define whether it
> supports the XPointer Framework (XPF).  I believe consistent
> compatibility with the XPF across XML-based media types would be a
> good thing. 

XPointer wasn't nearly cooked when RFC 3023 was written, and I don't
believe the notion of XPointer-as-Framework existed when it was going
through final revisions.

Developers can, of course, apply any flavor of XPointer or XPath to any
XML document they like.  And creators of new media types are allowed by
IETF rules to create fragment identification systems.  Those two
approaches may or may not overlap.

There's an uglier question - which could be addressed in depth for
eternity - about the use of fragment identifiers in URI references,
which leads me to consider the whole set of connections among these
mechanisms broken in practice if not in theory.  For a URI reference

The interpretation of the fragment identifier depends on the media type
returned.  URI philosophers will likely wave their hands and say this
isn't a problem. 

However, in practice the way the fragment identifier is actually
processed depends on the underlying media type, which can, er, vary,
thanks to mechanisms like content negotiation.  (That variation is the
good side of thinking in resources, but it complicates fragment
identifier processing.)

The problem gets more difficult as fragment identifiers grow more
specific to particular media types.

To modify Jonathan's preferred world:
> consistent compatibility with [some approach] across [all] media 
> types would be a good thing. 

...but it isn't going to happen.

The +xml set of questions seems to me just a subset of that larger set
of issues, and none of it seems likely to go away.

Simon St.Laurent
Retired editor, RFC 3023 

Received on Tuesday, 5 September 2006 15:44:12 UTC