Subject: RE: Comments on new draft of 3023bis (fragments, xpointer)
From: "Paul Grosso" <[email-masked]>
To: "Chris Lilley" <[email-masked]>
Cc: "Martin Duerst" <[email-masked]>, "Henry S. Thompson" <[email-masked]>, <[email-masked]>, "MURATA Makoto" <[email-masked]>, "Philippe Le Hegaret" <[email-masked]>
Date: Fri, 25 Feb 2005 10:01:41 -0500
List-Id: <ietf-xml-mime.imc.org>

> From: Chris Lilley [mailto:[email-masked]] 
> Sent: Friday, 25 February, 2005 7:15
> To: Paul Grosso
> Cc: Martin Duerst; Henry S. Thompson; [email-masked]; 
> MURATA Makoto; Philippe Le Hegaret
> Subject: Re: Comments on new draft of 3023bis (fragments, xpointer)
> 
> On Friday, February 25, 2005, 5:20:01 AM, Paul wrote:
> 
> PG> That's why I think it is important to say that the
> PG> fragment identifier syntax for the XML type is just
> PG> the XPointer Framework and Element() scheme, and
> PG> nothing else--all other schemes must be ignored.  
> 
> To be clear - you are saying that
> 
> - for application/xml
> - for unknown +xml media types being processed as xml
> 
> the fragment identifier syntax for the XML type is just the XPointer
> Framework and Element() scheme, and nothing else--all other 
> schemes must be ignored.

Correct.

> "Ignored" needs to be further defined (ie, it does not cause 
> an error).

I mean "ignored" in the sense that is defined in the XPointer Framework 
spec which explains how to handle an xpointer with schemes that are
not recognized/supported.  (I agree we need to get precise wording,
but I hope what I'm trying to say is clear by reference to the
XPointer Framework spec.)

> And to be clear, you are *not* saying that
> 
> - any +xml media type is forbidden from defining its own, richer,
> fragment identifier syntax in addition to that defined fro +xml as a
> whole.
> 
> Right?

Correct--another media type can say whatever it wants in this regard.

paul

Date: Fri, 25 Feb 2005 14:15:10 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: "Paul Grosso" <[email-masked]>
Cc: "Martin Duerst" <[email-masked]>, "Henry S. Thompson" <[email-masked]>, [email-masked], "MURATA Makoto" <[email-masked]>, "Philippe Le Hegaret" <[email-masked]>
Subject: Re: Comments on new draft of 3023bis (fragments, xpointer)
Sender: [email-masked]

On Friday, February 25, 2005, 5:20:01 AM, Paul wrote:

PG> That's why I think it is important to say that the
PG> fragment identifier syntax for the XML type is just
PG> the XPointer Framework and Element() scheme, and
PG> nothing else--all other schemes must be ignored.  

To be clear - you are saying that

- for application/xml
- for unknown +xml media types being processed as xml

the fragment identifier syntax for the XML type is just the XPointer
Framework and Element() scheme, and nothing else--all other schemes must
be ignored.

"Ignored" needs to be further defined (ie, it does not cause an error).

And to be clear, you are *not* saying that

- any +xml media type is forbidden from defining its own, richer,
fragment identifier syntax in addition to that defined fro +xml as a
whole.

Right?

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

Date: Fri, 25 Feb 2005 14:11:11 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: MURATA Makoto <[email-masked]>
Cc: [email-masked] (Henry S. Thompson), [email-masked]
Subject: Re: Comments on new draft of 3023bis
Sender: [email-masked]

On Friday, February 25, 2005, 1:19:23 PM, MURATA wrote:

MM> Henry,

MM> Given the unfortunate history (see below) of XPointer, I would
MM> like to introduce a bare minimum into the XML at this stage of 
MM> the game.

MM> XPointer was originally a small part of XLink (links for XML)
MM> in 1997.  But XPointer grew to become a single specification
MM> in 1999.  After the addition of the xmlns scheme, XPointer
MM> became too complicated as a single specification.  Thus, it
MM> was divided into four specifications (the framework, element
MM> scheme, xmlns scheme, and xpointer scheme) in 2002.  Three of
MM> them reached the W3C Recommendation status in 2003, but the
MM> other (the xpointer scheme) is still a working draft and it
MM> has not been revised since 2002.

MM> The XPointer framework allows other schemes to be added.  Some
MM> schemes have been proposed.  For example, SVG has its own
MM> scheme.  W3C may create a registry of such schemes, but we do
MM> not know when W3C will do so.

In effect, the individual media type registrations are that registry.
According to AWWW, the interpretation of a fragment identifier  is
solely in the context of the media type it is applied to. So in the SVG
example, the fragment scheme for SVG applies only to resources served as
svg. Similarlyfor WebCGM which defines its own fragment identifiers.

MM> Unfortunately, neither XLink nor XPointer has been widely
MM> implemented yet.  Even the framework and element scheme of
MM> XPointer have not been successful.  Let alone the xpointer
MM> scheme.  Some people are against the xpointer scheme, and 
MM> others are skeptical about the XPointer family as a whole.  
MM> A small subset of XPointer combined with XInclude is hopeful, 
MM> however.

The Xpath1 scheme is one such possible subset, although it does not seem
to be further developed.
http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-01.html

>> > Who maintains the registry of user-defined schemes?
>> 
>> The W3C has committed to doing so at some point, but no definitive
>> timeframe is known.

It has? Where?

MM> I think that this is already a good reason not allow user-defined
MM> schemes for application/xml.  When W3C is not willing to acknowledge
MM> other schemes, I do not think that IETF has to allow them.

>> > 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.

MM> A minimum conformance level of XPointer is not defined by 
MM> the XPointer recommendations.  You are proposing to define it 
MM> in the XML media type RFC.  I am not thrilled to do so.

>> 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.

MM> Sounds simple (in theory), but I am worried that the added complexity
MM> is good enough to hamper the adoption of XPointer. 

>> 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.

MM> Anyway, we will have to issue another RFC when W3C starts a registry of
MM> xpointer schemes.

MM> Cheers,

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

Date: Fri, 25 Feb 2005 21:19:54 +0900
From: MURATA Makoto <[email-masked]>
To: Martin Duerst <[email-masked]>
Subject: Re: Comments on new draft of 3023bis (fragments, xpointer)
Cc: "Paul Grosso" <[email-masked]>, "Henry S. Thompson" <[email-masked]>, [email-masked], Philippe Le Hegaret <[email-masked]>
Sender: [email-masked]

Martin,

As I said in my reply to Henry, I would like to allow a 
bare minimum as fragment identifiers for application/xml.

> 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 am happy to bless the element scheme only and not mention 
any other schemes.

> 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.

Here we disagree.  Given that XPointer has not been 
successful, I would like to keep fragment identifiers 
as simple as possible.

> 
> 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.

Both are attempts to define conformance levels of XPointer 
implementations.  Since the XPointer recommendations do not 
define such conformance levels, I do not want to try at IETF.

Cheers,

-- 
MURATA Makoto <[email-masked]>

Date: Fri, 25 Feb 2005 21:19:23 +0900
From: MURATA Makoto <[email-masked]>
To: [email-masked] (Henry S. Thompson)
Subject: Re: Comments on new draft of 3023bis
Cc: [email-masked]
Sender: [email-masked]

Henry,

Given the unfortunate history (see below) of XPointer, I would
like to introduce a bare minimum into the XML at this stage of 
the game.

XPointer was originally a small part of XLink (links for XML)
in 1997.  But XPointer grew to become a single specification
in 1999.  After the addition of the xmlns scheme, XPointer
became too complicated as a single specification.  Thus, it
was divided into four specifications (the framework, element
scheme, xmlns scheme, and xpointer scheme) in 2002.  Three of
them reached the W3C Recommendation status in 2003, but the
other (the xpointer scheme) is still a working draft and it
has not been revised since 2002.

The XPointer framework allows other schemes to be added.  Some
schemes have been proposed.  For example, SVG has its own
scheme.  W3C may create a registry of such schemes, but we do
not know when W3C will do so.

Unfortunately, neither XLink nor XPointer has been widely
implemented yet.  Even the framework and element scheme of
XPointer have not been successful.  Let alone the xpointer
scheme.  Some people are against the xpointer scheme, and 
others are skeptical about the XPointer family as a whole.  
A small subset of XPointer combined with XInclude is hopeful, 
however.

> > 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 think that this is already a good reason not allow user-defined
schemes for application/xml.  When W3C is not willing to acknowledge 
other schemes, I do not think that IETF has to allow them.

> > 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.

A minimum conformance level of XPointer is not defined by 
the XPointer recommendations.  You are proposing to define it 
in the XML media type RFC.  I am not thrilled to do so.

> 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.

Sounds simple (in theory), but I am worried that the added complexity 
is good enough to hamper the adoption of XPointer. 

> 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.

Anyway, we will have to issue another RFC when W3C starts a registry of 
xpointer schemes.

Cheers,

-- 
MURATA Makoto <[email-masked]>

Content-class: urn:content-classes:message
Subject: RE: Comments on new draft of 3023bis (fragments, xpointer)
Date: Thu, 24 Feb 2005 23:20:01 -0500
From: "Paul Grosso" <[email-masked]>
To: "Martin Duerst" <[email-masked]>, "Henry S. Thompson" <[email-masked]>, <[email-masked]>, "MURATA Makoto" <[email-masked]>
Cc: "Philippe Le Hegaret" <[email-masked]>
Sender: [email-masked]

Just a couple thoughts in return embedded below
in an excerpt of your email. 

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]] 
> Sent: Thursday, 24 February, 2005 18:11
> To: Paul Grosso; Henry S. Thompson; [email-masked]; 
> MURATA Makoto
> Cc: Philippe Le Hegaret
> Subject: RE: Comments on new draft of 3023bis (fragments, xpointer)
> 
> 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 can agree with that.  I think the xpointer scheme was
originally called out because of the confusion between
"XPointer" (Framework) which is a Rec and the "xpointer
scheme" which was what some folks thought xpointer was
going to be but which has basically been abandoned.
But at this point, I agree there is no strong reason
to mention it explicitly.

> 
> 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.

Saying other xpointer schemes are allowed but MUST be ignored
would be fine with me.  

> 
>  >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?

No, you're thinking about browsers "going" somewhere.

That's not the important case.  XML isn't primarily
about display, it's about information.  Xpointers
define a subresource that gets used in some fashion,
not just displayed.  It can make a big difference if
someone is using an xpointer to indicate what part of
an XML resource to use as an XSLT stylesheet or to
XInclude into a document and instead the entire XML
resource is used.

That's why I think it is important to say that the
fragment identifier syntax for the XML type is just
the XPointer Framework and Element() scheme, and
nothing else--all other schemes must be ignored.  

I don't want a lot of flexibility and extensibility 
here.  If someone wants extensibility, let them define 
another MIME type.

paul 

Date: Fri, 25 Feb 2005 09:11:16 +0900
To: "Paul Grosso" <[email-masked]>, "Henry S. Thompson" <[email-masked]>, <[email-masked]>, MURATA Makoto <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: RE: Comments on new draft of 3023bis (fragments, xpointer)
Cc: Philippe Le Hegaret <[email-masked]>
Sender: [email-masked]

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: [email-masked]
 >> [mailto:[email-masked]] On Behalf Of Henry
 >> S. Thompson
 >> Sent: Thursday, 24 February, 2005 8:11
 >> To: [email-masked]
 >> 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: [email-masked]
 >>                    URL: http://www.ltg.ed.ac.uk/~ht/
 >> [mail really from me _always_ has this .sig -- mail without
 >> it is forged spam]
 >>
 >> 

Content-class: urn:content-classes:message
Subject: RE: Comments on new draft of 3023bis
Date: Thu, 24 Feb 2005 09:53:13 -0500
From: "Paul Grosso" <[email-masked]>
To: "Henry S. Thompson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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-masked] 
> [mailto:[email-masked]] On Behalf Of Henry 
> S. Thompson
> Sent: Thursday, 24 February, 2005 8:11
> To: [email-masked]
> 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-masked]
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without 
> it is forged spam]
> 
> 

To: [email-masked]
Subject: Comments on new draft of 3023bis
From: [email-masked] (Henry S. Thompson)
Date: Thu, 24 Feb 2005 14:11:00 +0000
Sender: [email-masked]

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