RE: XPointer considered incomprehensible

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.

Fragment identifiers are in fact problematic, in that their
interpretation is dependent upon the media type of the resource.  This
interacts badly with content negotiation, as a given URL may return a
variety of media types, and if the fragment identifier syntax for each
of these media types is incompatible, the utility of the fragment
identifier is destroyed.

XPF deployment doesn't solve this universally, but it does provide a
mechanism to address this within the XML family of media types (or
actually, any media type with XPointer-framework compatible syntax.)

For example, say a description of a Web Service was deployed, with
content negotiation providing for application/wsdl+xml,
application/rdf+xml, or application/xml representations.  If each of
these media types were XPF-compatible, one could construct a fragment
that, while a bit hairy, could precisely identify a subresource within
any of these media types:

http://example.com/webservice#wsdl.interface(pay)rdf.about(pay)element(/
1/3)

(I just invented rdf.about() as an XPF-compatible synonym for whatever
#pay would mean.)

Unfortunately this doesn't work today:
- application/rdf+xml apparently doesn't use XPF.
- application/wsdl+xml inadvertently constrains away non-wsdl.* schemes
(I will get this fixed this asap.)

The problem is in education and evangelization - the value of XPointer
is proportional to the number of media types that make use of it.  Is
there more we can do to jumpstart the network effect?  Perhaps the TAG
can survey the +xml media types and determine how many aren't
compatible, and apply some pressure to get them fixed.

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Tuesday, September 05, 2006 7:03 AM
> To: Bjoern Hoehrmann
> Cc: Jonathan Marsh; www-tag@w3.org; www-xml-linking-comments@w3.org
> Subject: Re: XPointer considered incomprehensible
> 
> Bjoern Hoehrmann writes:
> 
> > We currently do not have a sound architecture built around the many
> > XML media types. We do not have specifications that address cases
> > like the one you cite - SVG content labeled application/xml - in any
> > way. My understanding is that web browsers tend to consider all the
> > XML media types (*/xml and */*+xml) exactly the same. There isn't
> > much wrong with that so long as they actually are the same, but at
> > least in case of fragment identifiers, they are not.
> >
> > I recently researched the registered +xml media types for what their
> > specifications say about fragment identifiers and found that only
> > three type make an attempt to say something about the matter by
them-
> > self:
> >
> >   * application/xhtml+xml       -> Probably ID references
> >   * application/smil+xml        -> as above plus maybe XPointer
> >   * application/rdf+xml         -> I don't understand the RFC
> >
> > Then there are two types that refer to application/xhtml+xml, nine
> > types that refer to application/xml, and the other 57 types do not
> > define their fragment identifier syntax, if any. My understanding is
> > that some people propose application/xml should allow for any and
all
> > XPointer schemes; if we do that, it would become, in a way, the
super-
> > type for all XML media types, whereas people currently tend to think
> > of it as a base type.
> 
> I note that RFC 3023 [1] says of xxxx+xml media types:
> 
> "This document recommends the use of a naming convention (a suffix of
> '+xml') for identifying XML-based MIME media types, whatever their
> particular content may represent.  This allows the use of generic XML
> processors and technologies on a wide variety of different XML
document
> types at a minimum cost, using existing frameworks for media type
> registration.
> 
> [...]
> 
> Some areas where 'generic' processing is useful include:
> 
>    o  Browsing - An XML browser can display any XML document with a
>       provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
>       that document.
> 
>    o  Editing - Any XML editor can read, modify, and save any XML
>       document.
> 
>    o  Fragment identification - XPointers (work in progress) can work
>       with any XML document, whatever vocabulary it uses and whether
or
>       not it uses XPointer for its own fragment identification."
> 
> So, the architecture seems to be:  XPointer must be usable with any of
the
> +xml family.  There is at least a hint that the specific xxxx+xml
media
> type need not use XPointer for its own fragment identification.  This
> seems a bit strange to me, but it obviously was carefully considered
when
> 3023 was drafted.
> 
> Noah
> 
> [1] http://www.rfc-archive.org/getrfc.php?rfc=3023
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
>

Received on Tuesday, 5 September 2006 15:15:43 UTC