Re: [xml-dev] Simplified XPointer

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


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

> 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

image/gif

Does XPath make _any_ sense, well yes, suppose:

/image/row[45]/point  or
/image/comment[3]

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

Jonathan


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>

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