- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Tue, 05 Sep 2006 05:18:42 +0200
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: <www-xml-linking-comments@w3.org>, <www-tag@w3.org>
* 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