[
Lists Home |
Date Index |
Thread Index
]
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
|
