At 00/09/26 10:50 -0400, Eve L. Maler wrote:
At 02:40 PM 9/26/00 +0900, Martin J. Duerst wrote:
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.
Okay, so the XPointer errata are a hook to whatever may happen
in the future, rather than the actual location of a registry.
I think that makes sense.
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.
I think that works very well is a given media type wants to define
a subset of the xpointer scheme, for example.
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.
I'm not sure that the IETF media type registry is very efficient for this.
If somebody has a new idea for an XPointer scheme foo(), they would have
to search through all registered types (not only the +xml types, because
as far as I understand, there is no MUST to register an xml type with
+xml). That's really a lot.
On the other hand, I think that the list of XPointer schemes should be
kept very small, and that it will stay very small. For example, SVG
doesn't define an svg() scheme. The most obvious candidates are
for temporal and spacial identification for audio, video, and graphics.
Because of this small number, I think it would be very good to actually
maintain a list of pointers (e.g. in the XPoiter errata or in a
document pointed to from there), whereas the actual definition of
a new scheme could be in the IETF media types registry or in the
spec of a document type referenced from there.
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.
It defines the +xml convention, and therefore can say what a document
type has to do to fit this convention.
Regards, Martin.