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.
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?
Regards, Martin.