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:chris(_at_)w3(_dot_)org
Chair, W3C SVG Working Group
W3C Graphics Activity Lead