Re: Rough sketch for an I-D (a successor of RFC 3023)

chris@w3.org (Chris Lilley) writes:
>I read your message above and was confused, because you chose to base
>one of your own specifications on the XPointer framework and schemes.

It was written before the namespaces-for-all-non-W3C-schemes nonsense
made a last-minute leap into the specification.

>> This document specifies an xpath1() scheme for use in XPointer-based
>> fragment identifiers. This scheme, like other XPointer Framework[11]
>> schemes, is designed primarily for use with the XML Media Types
>> defined in RFC 3023[5], to identify locations within a given XML
>> representation of a resource. The xpath1() scheme uses XPath 1.0
>> syntax
>http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-00.html
>
>Or did your scheme avoid the architectural flaws that you see lurking?

Not all of them - the issues around parens are especially difficult for
an XPath-based syntax.  

You do, however, appear to be looking at an older draft.  The more
recent (not much more recent, admittedly) draft is at:

http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-01.html

Worth noting in Section 8, Conformance, is this:
'This specification normatively depends on the XPointer Framework[12],
except insofar as it rejects the claim in Section 3.3 that "this
specification reserves all scheme names for definition in additional W3C
XPointer scheme specifications"'

That refers to a prior XPointer Working Draft, the 10 July 2002 draft. 
I should probably do a quick revision which updates the conformance
section to:
"This specification normatively depends on the XPointer Framework[12],
except insofar as it rejects the claim in Section 3.3 that "This
specification reserves all unqualified scheme names for definition in
additional XPointer schemes defined in W3C Recommendations."'

When it leaped from Last Call WD to PR, the XPointer WG apparently
decided to add the baggage of QNames to schemes in a Framework which has
no pre-existing namespace context.  

As a result, if I considered the W3C approach wise, URIs with xpath1()
fragment identifiers would have to look like:

http://simonstl.com/articles/sanity/#xmlns(s=http://simonstl.com/ns/
bogus/)s:xpath1(/html/head/title)

instead of:
http://simonstl.com/articles/sanity/#xpath1(/html/head/title)

If my schemes are going to have to look like that - and worse, work like
that - I'm not going to create them.  It's not worth bothering, they're
not worth typing, and every time I have to write a superfluous namespace
declaration I'm reminded that the W3C exempted itself from this
nonsense.

So far as I have heard, the W3C and I are the only people publishing
XPointer schemes.  The five I published are available at:

http://simonstl.com/ietf/

The dates on the drafts likely suggest when I lost interest in XPointer
work.  I find the use of QNames for schemes an execrably misguided
decision, and regard the reservation of unqualified scheme names a
blatant attempt to shield the W3C's own work from the dire consequences
of that approach.  

Hence, I reject that 'reserves' claim entirely. Beyond that, however, I
see the XPointer Framework as deeply flawed for imposing a QName-based
scheme approach inside of a context-free URI.   QNames complicate XML
tremendously to start with, but XPointers can't even take advantage of
all that context machinery.  Even schemes, it seems, are forced to
declare namespaces, nesting URIs inside of URIs merely to determine what
the fragment identifier does.  It's especially amusing for pointers into
documents which don't themelves use namespaces.

As no one outside of the W3C seems excited about XPointer anyway, I see
no reason to encourage its adoption by creating and publicizing new
schemes for it.  I'd much rather see it deprecated, replaced, and
forgotten.

Received on Sunday, 2 November 2003 15:39:29 UTC