Tim Bray wrote:
Right. I think that the +xml idiom is useful even if it doesn't guarantee
that such documents are going use XLink/XPointer for outgoing links.
Right.
I hadn't considered outgoing links, but I don't believe them relevant to
this discussion. Only the processor of the document that is referenced
should care.
Hmm, it also seems that anything that's of type *+xml has, per definition,
internal structures which can be addressed by xpointer whether the
media-type designers foresaw that or not. -Tim
Well, you're right if you're talking about doing this all by hand,
outside the context of an architecture, i.e. if you just pass (however
you want to do it) an SVG document to an XML processor that supports
XPointer, then you can address that SVG with XPointer. No problem.
The issue is, in the context of MIME dispatch, what can the *dispatched*
processor be guaranteed to interpret for us.
From RFC 2396, 4.1;
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.
Which means that if a processor is dispatched to handle a particular
media type, then it is the registration of that media type that defines
the normative syntax to be used to reference its internal structure via
that processor. In other words, there's no guarantee that the processor
can interpret XPointer fragment identifiers.
If you want to use the knowledge that the media type ends with "+xml" to
dispatch to a {text|application}/xml processor instead, then that will
give you XPointer (though draft-murata-xml references it
non-normatively, due to the scheduling problem I assume). But a content
author is now SOL in terms of being able to guarantee that there's any
further dispatch to the SVG processor (see draft-murata-xml section 3,
last paragraph), so the image may not get displayed.
MB