Re: Comments on new draft of 3023bis

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 protected]>