Re: XPointer considered incomprehensible

* Jonathan Marsh wrote:
>Interesting post.  I helped develop XPointer, so I included some
>comments defending the framework below.

Thank you for your response Jonathan. I note that Henry S. Thompson
also replied, see the www-xml-linking-comments list archives.

>The XPointer Framework is intentionally vague about what constitutes a
>sub-resource, in order to delegate that determination to each scheme. 
>For barenames, there is an implication that the subresource would be an
>element information item, as that is the only thing identified by such a
>pointer.  I suppose it wouldn't hurt to spell this out more clearly.

Yes, I suppose the XPointer Framework is not meant to restrict the
kind of resource a XPointer fragment identifier can identify, but
this isn't very clear from the specification. Henry suggested that
instead of "subresource" the term "secondary resource" should be
used with reference to RFC 3986.

>Fragment syntaxes need to be evaluated in the context of a media type.
>In looking more closely, I see that the definition of SVG fragment
>identifiers doesn't seem to allow for extended or multiple XPointer
>schemes.  Your example would not AFAICT be a valid fragment identifier
>for image/svg+xml.  Despite the syntactical similarity, SVG fragment
>identifiers apparently don't conform to the XPointer Framework.

There are actually multiple specifications for image/svg+xml fragment
identifiers, the old SVG 1.1 Recommendation and the recently published
SVG Tiny 1.2 Candidate Recommendation:

  * http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
  * http://www.w3.org/TR/SVGMobile12/linking.html#SVGFragmentIdentifiers

The later specification is syntactically a subset of the former, and
the processing semantics of the #barename form have been changed. While
this form would still identify the same element, viewers have to pre-
sent the documents differently: in SVG 1.1 they would render the whole
document, and in SVG Tiny 1.2 viewers would, essentially, zoom the
element into the view.

I am not yet sure what to make of the syntax differences, I don't know,
for example, whether SVG 1.1 fragment identifiers can be used for SVG
Tiny 1.2 documents, and I'm unsure whether I could use other XPointer
schemes with SVG 1.1 documents. As it stands it seems pretty clear
though that my example is non-conforming. Both specifications don't
address how to process non-conforming fragment identifiers; if the
viewer supports other XPointer schemes, reasonable error recovery might
be to simply process the other schemes as if they were allowed...

>They've profiled away the extensibility mechanism which is 90% of the
>framework.  So while svgView could be used legally as an XPointer
>scheme, it apparently can't be considered such within the context of
>image/svg+xml.  There doesn't seem to be any claim that the fragment
>syntax is XPointer compatible, so the wrong impression must simply come
>from the registration as an XPointer scheme, where it's utility within
>XPointer appears largely useless.

I think the registration of svgView as XPointer scheme does make some
sense if you assume that other XPointer schemes can be used with SVG
content; the registration would ensure that no one else registers a
'svgView' scheme that, then, cannot be used with SVG as it already has
its own 'svgView' scheme.

The general problem here is that the XPointer Framework specification
does not really discuss what specifications of XML Media Types have to
do in order to achieve compatibility with the XPointer Framework, and
there are media types like application/rdf+xml that are fundamentally
incompatible with XPointer.

>The spec doesn't say that.  It says "If the XPointer processor does not
>support the scheme used in a pointer part, it skips that pointer part."

Whether the 'svgView' scheme would be ignored depends on whether it
identifies a "subresource", and the XPointer Framework can be read
to imply that only XML subresources within an XML resource can be
identified, which would exclude the view identified by svgView. If
svgView does identify a subresource, then they don't ignore it.

>If your example were to be associated with the application/xml media
>type, the svgView scheme is most likely (but not necessarily!) not
>supported, and the processor will therefore skip that part.

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.

>As I said, I don't think SVG conforms to XPointer, but that appears to
>be a choice/bug in svgView rather than a fundamental problem with
>XPointer.  That they have muddied the waters by reusing a similar (but
>subtly different) syntax and registered the svgView scheme as if it were
>likely to be used in an XPointer Framework-compatible way is certainly
>unfortunate.

The interactions between SVG fragment identifiers and XPointer are at
least unclear at this point. This obviously makes "generic" XML pro-
cessing rather difficult; suppose you create a standard to include
some XML fragments from one document into another, just by having

  <include src='example#element(/1/2/3)' ... />

in the document. Now, whether this will work depends on the MIME type
of the resource, if the type is known to the implementation and the
type is known to support XPointer, this will work fine. If the type
is not known, it's not clear what the implementation should do. If it
is a +xml type, it might assume it's using XPointer and process it
accordingly. If, however, the document is a application/rdf+xml re-
source, that would be contrary to the definition of the type.

In the end, such differences make deployment of new types expensive
(more expensive than it already is) since you cannot use the type
even if the implementation already supports the desired features,
just because you used the new type instead of, say, application/xml.
Architecturally, that's not very good...

XInclude works around this problem by splitting resource identifier
and XPointer in separate attributes. This has its own problems. If
you consider a packaging format (such as the one the Web Applications
Working Group is developing), it might be possible to address the
files included in such a package using fragment identifiers

  http://example.org/package#file1.xml

and secondary resources of that file

  http://example.org/package#file1.xml%23element(/1/2/3)

but it is impossible to use this with XInclude as it disallows the
use of fragment identifiers in the href='' attribute, and as the
package format might not be an XML format, the xpointer='' attribute
cannot be used either.

>There is a difference between a legal XPointer scheme and a media type
>registration that builds on the XPointer framework.  The case of svgView
>shows that it would be nice to confirm that a scheme is actually useful
>as an XPointer before registering it.  This is a problem in inadequately
>reviewing SVG as much as in reviewing the svgView scheme in isolation.

Yes, that's in fact another question the XPointer Framework does not
really answer. Is there an implied requirement that schemes can be
applied to more XML documents than just those of a specific type?

>Yes, some are way underspecified.  While I'm not sure the Registry is
>about making sure each scheme is of high quality, it's simply about
>avoiding name conflicts, it would be nice to have a requirement that
>there is a link to a spec (otherwise, reserving the name serves no
>purpose, does it?)

My understanding is that there is no requirement to actually have a
specification; in case of the xpath2 scheme, it seems that the short
description given in the registration is the only specification we
have.

>I also see all the WSDL ones (which my own WG is responsible for)
>have been marked as registered despite the policy stating that the
>corresponding spec needs to be in PR first (which it's not.)

Good catch! I did not notice that requirement. The xpointer() scheme
is also marked "Registered" even though there is only an outdated and
unmaintained Working Draft.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 5 September 2006 03:19:01 UTC