[
Lists Home |
Date Index |
Thread Index
]
Jonathan Robie wrote:
> >The essence: this syntax is suitable for use as a frag
> >id syntax for media type application/xml and text/xml.
>
> Cool!
thanks.
>
> >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.
>
Oops, that was an oversight. the EBNF should read:
FragmentID := (Name, NumberPart) | NumberPart ...
> >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?
>
A couple of options:
1) a media type registration would declare particular schemes and what the fragment identifies with respect to the particular media type.
2) A RDDL document can declare support for a particular scheme as described, the references resource (e.g. xlink:href) identifies the specification for the particular scheme e.g. full xpointer, xpath etc.)
The details of how this should be done need to be better fleshed out. On the other hand we might just punt on that one and let this be entirely up to the media type registration, i.e. this remains a purely syntactic description.
The advantage of having a purely syntactic spec, is that XPath etc. already have robust, and getting more so, formalisms.
Jonathan
|
