XPointer scheme names (was Re: Conformance value of "+xml"?)

["Eve L. Maler" <[e-mail]>]

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                                          [phone]
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com