The new draft [1] says
5. Fragment Identifiers
. . . [XPointer s]chemes other than the element scheme MUST NOT be
specified as part of fragment identifiers for these media types. In
particular, the xpointer scheme MUST NOT be specified since it is
still at the W3C working draft stage.
I said about this to MAKOTO Murata
This seems overly restrictive to me. The xpointer framework provides
for user-defined schemes, and I already know of several
implementations of the xpointer scheme -- it seems unhelpful at least
to say I MUST NOT use them.
He replied:
I am sure that there are some implementations of the xpointer scheme.
However, since xpointer is still a working draft, these implementations
are not conformant and they are very unlikely to be interoperable. The
XPointer WD says "It is a draft document and may be updated, replaced,
or obsoleted by other documents at any time. It is inappropriate to use W3C
Working Drafts as reference material or to cite them as other than 'work
in progress'".
As for user-defined schemes, you can always create a specialized media
type. For example, SVG has its own scheme, which is useful for
specialized media types for SVG. If we allow user-defined schemes for
application/xml, the definition of XML fragment identifiers becomes
open-ended. This begs significant questions. Does the current
registration procedure of media types allow such open-ended definitions?
I don't see why not.
Who maintains the registry of user-defined schemes?
The W3C has committed to doing so at some point, but no definitive
timeframe is known.
I do not want to open this can of worms at this stage of the game.
I guess I do. The XPointer framework spec. is intentionally
open-ended, _and_ it makes clear that only shorthand pointers
(i.e. #+barename) MUST be supported, and clearly provides for
processors to fail if they encounter a scheme they don't support.
Seems to me straightforward for 3023bis to say, consistently with
that, that shorthand and element schemes must be supported, and that other
schemes may be used but SHOULD be avoided for interoperability unless
the scheme is appropriately registered and standardised.
The tremendous advantage of doing it this way is that 3023bis does not
then have to be re-issued every time a new XPointer scheme is blessed.
ht
[1] http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-01.txt
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
Half-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail:
ht(_at_)inf(_dot_)ed(_dot_)ac(_dot_)uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]