Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
