At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote:
At 00/09/25 17:04 +0200, Chris Lilley wrote:
> For the fifth paragraph I'd recommend changing the wording to reflect
> that for fragment identifiers at least, registrations are free to
> *extend* the syntax, but must at least support the XML syntax;
In the case of SVG, since there seemed to be little prior experience with
the full complexities of XPoinbter, SVG supports a subset of the syntax. So
the uses in an SVG instance will all conform to the XPointer spec, but the
converse is not true - not all valid XPointers are guaranteed to be
processd by SVG-aware user agents.
XPointer, at http://www.w3.org/TR/xptr#schemes, says how
such extensions can happen. I think the RFC should make sure
that it references that part or is otherwise in sync with it.
So what I would like to see here is some text that says that
any registrations must use a subset of the XPointer syntax.
For new applications, that means that if they need an xpointer
scheme not currently in the xpointer TR, they have to make sure
it gets registered by getting added to the XPointer errata document.
I like the idea of defining subsets of XPointer for the fragment
identifiers into their XML-based languages. However, I'm not crazy about
having to modify XPointer through errata every time. We were required to
remove the "arbitrary scheme" functionality in XPointer in order to avoid a
situation where designers choose conflicting scheme names; the note about
"errata" that's in there now is just because we weren't sure how we were
going to get out of this mess, and we wanted to keep people informed.
Murata Makoto has since pointed out to me that we simply need to rely on
the system of IETF media type registration documents to avoid this. In
this manner, SVG could perhaps define its fragment identifier language to
be a "subset" of XPointer that consists of an svg(...) scheme plus a few
things from the xpointer(...) scheme. No one else could choose "svg" as a
scheme name and get away with it.
Does this make sense to all you experts?
The registration should then document which part of XPointer it
supports.
For interoperability, this means that any +xml type will support
a subset of XPointer as a fragment identifier. Some may only support
the bare #<identifier> syntax, some may add #xpointer(id(<identifier>))
as SVG did, some may support the full xpointer scheme, some may
support some other scheme (e.g. a temporal scheme for audio or video,...).
The interoperability guarantee that this gives is that it is not possible
to construct a fragment identifier that means one thing for one type
and another thing for another type. Either it means something for
a given type, or it's not understood for that given type.
I'm not sure I'm happy with this; defining a minimum that every
+xml type has to support would be very desirable in my eyes.
That's one of the ideas behind the +xml suffix, isn't it.
So how should this minimum look like?
Does a document such as draft-murata-xml-0[78] have the "right" to define
such a minimum? If so, I'd be very interested to hear what people think it
should contain.
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ east.sun.com