Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
