W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2002

Re: [xml-dev] Simplified XPointer

From: Jonathan Borden <jborden@attbi.com>
Date: Sat, 23 Feb 2002 08:21:40 -0500 (EST)
Message-ID: <040401c1bc6c$eb05cbc0$0301a8c0@ne.mediaone.net>
To: <xml-dev@lists.xml.org>
Cc: <www-xml-linking-comments@w3.org>

A few points of clarification based on some private and/or out of band

> We have submitted an Internet Draft of a "generic
> fragment identifier syntax" which is suitable for
> service as a simplified version of XPointer.
> http://ietf.org/internet-drafts/draft-borden-frag-00.txt
> The essence: this syntax is suitable for use as a frag
> id syntax for media type application/xml and text/xml.

Actually this syntax represents _full XPointer_ as well. I should have been
more clear about this. The I-D is designed to represent the syntax of
XPointer (but not the semantics). It does not define any mapping of fragment
identifiers to locations within a document.

In the case of bare name fragment ids, XML 1.0 already defines the mapping
of a Name to an element via an ID attribute.

In the case of the XPath scheme, the XPath recommendation already defines
the mapping of a path to a nodelist.

In the case of the XPointer scheme, the XPointer WD defines essentially an
extended path that has ranges etc.

The possible simplification is that a media type registration (for example)
would be able to choose which schemes are to be included for the particular
media type. Unregistered schemes would likely be ignored however the
_behavior_ remains up to what is specified in the media type registration.

> Like the current version of XPointer it
> has 3 forms:
> 1) bare names e.g. #foo
> 2) short refs e.g. #/1/2

As has been pointed out, it is not at all clear that a numeric range has any
meaning across media types. Even within a media type (e.g. for an XML
document) numeric ranges are quite fragile with respect to editing.
_However_ since there are numeric frag ids in current use, we thought this
should be part of the _syntax_.

I am not at all sure that numeric identifiers have any meaning independent
of media type, perhaps the I-D needs to state that. Does anyone think

> 3) scheme based fragments  e.g. #xpath(/foo/bar[3])
> The draft proposes 3 predefined scheme based fragments:
> 1) xpath(path)-- the parameter is an xpath

To clarify: for XML this makes perfect sense, what about for something like


Does XPath make _any_ sense, well yes, suppose:

/image/row[45]/point  or

so ala a 'Grove', an  XPath can indeed make sense for non XML data.

> 2) xmlns(pre=URIref)-- the parameter is a prefix
> namespace binding (sets contextfor xpath)
> and currently:
> 3) xpointer(fullXptr) the parameter is a full XPointer
> as per WD

What is new, is that the XPath scheme is being introduced. Since the
semantics of an XPath are already defined, and there are many software
implementations, this seems a "low cost" facility to have in XPointer.

> It would be possible to drop the xpointer scheme and
> this draft becomes a very compact fragment identifier
> syntax for XML -- as well as being patent unencumbered

I don't mean to suggest that I favor dropping full XPointer, I do understand
that many people have a real need for ranges. What to do with the current
XPointer is up to the W3C WG. However, I strongly favor getting something
out the door _quickly_ because the absense of an XPointer _recommendation_
is a nagging architectural hole in XML and its relationship to the Web.

The patent unencumbered issue I think is not really much of an issue,
particularly given Sun's very liberal license. I do have a general issue
with patent encumbered 'standards' because my view of a standard is that it
should be freely available. But this is really outside the current

Received on Saturday, 23 February 2002 11:54:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:59 UTC