[
Lists Home |
Date Index |
Thread Index
]
Gustaf Liljegren said:
> Some questions about the XPointer Framework:
>
> 1. "An XPointer processor takes as input an XML-encoded resource and a
> fragment identifier taken from the URI reference that was used to
> access the resource, and produces as output either an identification
> of some subresource within that resource based on the pointer
> extracted from the fragment identifier, or one or more errors, or
> both."
>
> What is an "identification of some subresource"? The only resonable
> output from an XPointer expression I can think of is an XML fragment.
Pretty much, but keep in mind that the output might not be
well-formed XML, since handling "click and drag" selections
by users was a major use case. There is also the issue of the
stalled "XML Fragment" specification. Therefore, it seemed
best not to call the identified subresource an "XML fragment".
> As I understand it, XLink and XPointer are specs meant to acctually
> *do* something (fetch a document or fragment), while XPath is just a
> syntax for pointing at things.
To be pedantic, it is actually the application that calls an
XPointer (or XLink) processor that does something. XPointer is
just a URI fragment identifier syntax for identifying portions
of XML documents. XLink is just an XML syntax for asserting
relationships between things.
> 2. In "XML Bible" (1999) I read about two other problems surrounding
> XPointers:
>
> - In practice, HTTP can't deliver fragments, only whole documents.
It would be possible to tell the server to deliver some portion of
the resource by using '?' instead of '#'. However, that is not what
XPointer set out to do (and I'll avoid any further digression into
query syntax).
The '#' delimiter in a URL means the server is supposed to deliver
the whole resource, then the client is to dig through it to find
the part identified by the 'fragment identifier', which is the portion
of the URL after the '#'. The group is defining syntax for fragment
identifiers.
> - Fragments are not valid XML, sometimes not even well-formed.
As mentioned above, being able to deal with the kinds of
selections users would make during editing and annotating means
that XPointer MUST be able to identify non-well-formed portions
of well-formed XML documents.
> 3. "...this specification reserves all scheme names for definition in
> additional W3C XPointer scheme specifications. However, the scheme
> mechanism provides a general framework for extensibility..." Where's
> the extensibility? If I can't name my own scheme, then the
> extensibility is only in the hands of W3C, right?
This is addressed in the draft currently being reviewed by the
working group. It defines the scheme names to be QNames, and
reserves the unprefixed names for use in W3C Recommendations.
> 4. The comma in production [3] should be removed, shouldn't it?
Yes. That is also fixed in the new draft.
Best regards,
Ron Daniel Jr.
Acting chair, XML Linking Working Group
|
