I have read the relevant part of the new draft, and I have
to say that I have to agree with Henry on this point.
First, I think that the sentence:
"In particular, the xpointer scheme MUST NOT be specified
since it is still at the W3C working draft stage."
is rather inappropriate. There is nothing special to the
xpointer scheme here; there may be many other schemes that
are still at a draft stage at one point or another.
I understand that some people like the xpointer scheme,
and others don't like it at all, (and I personally don't
really care too much,) but we can just avoid a lot of
discussion if we simply don't talk about it.
Saying something like "In particular, schemes that are
still at working draft stage MUST NOT be used." also
doesn't make much sense, because in some sense, it doesn't
state anything more than the obvious, and in another sense,
it would look like it would prohibit experiments.
On top of that, there would be the question of why
xpointer needs to be called out specifically if the use
of any other schemes is prohibited anyway. But I think
prohibiting the use of any other schemes is a bad idea,
and is in conflict with the spirit if not the wording
of the XPointer Framework.
I think there are still at least two ways we could define
things to work:
a) Other XPointer schemes are allowed but SHOULD/MUST be ignored.
b) Other XPointer schemes are allowed and MAY be interpreted,
but there is no guarantee that any receipient will understand
any of them.
The reason that I think we should at least have a) is that
the XPointer Framework includes this facility for fallbacks,
and that this may help for fragment ids to work across different
resource types. The typical example would be an application/xml
and an image/svg+xml document that are content-type negotiated
(the SVG document is sent to user agents that advertise that
they know SVG,...). Using the XPointer Framework, it may be
possible to construct a fragment identifier that points to
a particular part of the graphics in the SVG document, and
to the data about that part in the application/xml document.
Disallowing other XPointer schemes would make the above impossible,
which I think would be a pity.
I'd personally be fine with either a) or b) above, but I think
being more restrictive than a) is unnesessary and counterproductive.
Even in the case of b), things would be written clearly enough
to make sure that interoperability expectations are not set
too high. We could even extend b) to say:
c) Other XPointer schemes are allowed and MAY be produced if
there is at least also a shorthand pointer (barename) or
an element pointer, and MAY be interpreted, but there is
no guarantee that any receipient will understand
any of them.
But I'm not sure we need to go there; there may be cases where
the sender decides that the best fallback for a pointer of
a special scheme is just the document as a whole.
[more short comments below]
At 23:53 05/02/24, Paul Grosso wrote:
>
>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.
Giving clear guidelines on what is expected to interoperate
is definitely very good.
>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.
We can clearly express the expectations. And those who don't
get it will find out soon enough.
>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'm not sure about this, but if that happens, people will
just get what they asked for. (but also see my proposal
c) above).
>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.
Agreed.
>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.
Agreed. But if the sender says "I want you to get exactly
here, and if that doesn't work, I don't care if you only
get the document overall", that's just fine, isn't it?
Also, if simple fragment identifiers are good enough for
most cases, that's where we will get interoperability
anyway, and we don't have to be worried too much.
>[Disclosure: I have always been opposed
>to the xpointer scheme from day 1 of the XLink WG.]
The xpointer scheme is currently a WD "in limbo", so no
reason to worry about it too much, I guess.
>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,
Yes indeed.
>> >and I already know of several
>> > implementations of the xpointer scheme
Well, given that the xpointer scheme is only a WD,
I don't think this is a good example. Of course one
can experimentally use not-yet-well-defined schemes
with experimental implementations, but to say something
in the direction of "I want you to allow other schemes
because I want to officially use xpointer now." is
not a very well-based request, and I understand that
some people who are not particularly fond of the XPointer
scheme get a bit nervous when they see that.
>> -- it seems unhelpful at least
>> > to say I MUST NOT use them.
I general, I agree.
>> 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'".
Very true. But because the XPointer scheme WD already says
so clearly, there is no need to mention the XPointer scheme
in 3023bis.
>> > 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.
If it really follows the XPointer Framework, it is already in
some sense 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.
If you have any input on the registration procedure,..., please
contact Philippe Le Hegaret (cc'ed).
>> > 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.
I think we don't even have to talk about registered vs. unregistered
schemes. Also, I'd rather talk positively about how other schemes
MAY be used. The above sentence can be read as "other schemes SHOULD
NOT be avoided if the scheme is appropriately registered and
standardized", which may be too encourageing.
Regards, Martin.
>> 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]
>>
>>