RE: Comments on new draft of 3023bis

I'm not 100% certain of my position, but I tend to
agree with Makoto here.

When talking about something as potentially ubiquitous
as fragment identifiers in URI references to XML resources,
I'd rather restrict them to something relatively simple
that we can be sure will work interoperably.  

I would not like someone to think they can use the xpointer 
scheme because it happens to work with their particular tool 
set only to find out that it doesn't work when they send it 
to someone else with a different tool set. 

I realize the xpointer framework defines how to give a single
multi-schemed xpointer that provides fallbacks, and this is
supposed to allow someone to (try to) use, say, the xpointer
scheme but then fallback to the element scheme.  But in 
practice, many people will just use the single scheme that 
works for them, and we'll be back in the non-interoperable 
situation quickly.

I guess I see no reason to revise 3023 "every time a new
xpointer scheme is blessed."  I don't want new xpointer
schemes getting blessed by 3023.  I want a relatively
simple fragment identifier for XML, and I don't really
want it to keep growing.  We're talking about something
that needs to be processed every time someone clicks on
a URI that references an XML resource, and we don't need
complexity here.  [Disclosure:  I have always been opposed
to the xpointer scheme from day 1 of the XLink WG.]

paul [speaking only for myself]

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Henry 
> S. Thompson
> Sent: Thursday, 24 February, 2005 8:11
> To: [email protected]
> Subject: 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-x
ml-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]
> 
>