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: owner-ietf-xml-mime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-xml-mime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Henry
S. Thompson
Sent: Thursday, 24 February, 2005 8:11
To: ietf-xml-mime(_at_)vpnc(_dot_)org
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:
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]