[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Simplified XPointer

• To: jborden@a..., xml-dev@l...
• Subject: Re: Simplified XPointer
• From: Jonathan Robie <jonathan.robie@s...>
• Date: Fri, 22 Feb 2002 10:23:41 -0500
• In-reply-to: <20020222132444.LBIW2626.rwcrmhc51.attbi.com@rwcrwbc57>

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

• References:
  • Simplified XPointer
    • From: jborden@a...

• Prev by Date: RE: 14 Theses around "Namespace Documents"
• Next by Date: RE: 14 Theses around "Namespace Documents"
• Previous by thread: Simplified XPointer
• Next by thread: Re: Simplified XPointer
• Index(es):
  • Date
  • Thread