Comments on new draft of 3023bis

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: [email protected]
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]