OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Simplified XPointer

[ Lists Home | Date Index | Thread Index ]

At 01:24 PM 2/22/2002 +0000, jborden@attbi.com wrote:
>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.

Cool!

>Like the current version of XPointer it
>has 3 forms:
>
>1) bare names e.g. #foo
>2) short refs e.g. #/1/2
>3) scheme based fragments  e.g. #xpath(/foo/bar[3])

Some of the refactoring proposals have suggested that (1) and (2) can be 
combined, allowing tumblers to follow bare names, which must occur first:

         #foo/1/3

Is there any reason not to support that? It seems useful.

>The draft proposes 3 predefined scheme based fragments:
>
>1) xpath(path)-- the parameter is an xpath
>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

I did not understand the section on "Declaration of Support for Schemes". 
The existence of the section implies that it is not necessary to support 
all schemes. What options does an implementation have, and how do they make 
known what it is they do and do not support?

Jonathan





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS