At 10:57 AM 5/28/99 +0900, MURATA Makoto wrote:
It appears that media types, fragment identifiers, and XPointer are
actually related.
This is an important question that operates on several levels. Fragment
identifiers (and supporting linking mechanisms) are a 'generic' tool that
can be used with any XML document. On the other hand, not all applications
using XML will support fragment identifier processing. XLink (ancient but
current draft, 3/98) suggests that regular #xxx identifiers be processed on
the client, and gives a query syntax for getting the fragment from the
server, but this infrastructure seems inadequate.
XPointer is intended to be used as a fragment identifier.
"The locator for a resource is typically provided by means of a
Uniform Resource Identifier, or URI. XPointers can be used as fragment
identifiers in conjunction with the URI structure to specify a more
precise
sub-resource."
I personally have expected that XPointer is usable for every XML document
no matter what the media type is. But I am apparently wrong. Do we need
a top-level media type "xml" or some convention such as "image/xml.vml"
so that XPointer can be used for any XML document? Or, are "text/xml" and
"application/xml" enough?
XPointer should be usable for every document that is a well-formed XML
document, whatever the media type. However, software is going to need to
know that the document is indeed XML to know how to interpret the
XPointer... XPointer is an excellent example of a generic XML tool that
works with any XML document in a wide variety of of different situations.
There's still the issue of who does what processing. I'm not thrilled with
the XLink proposals for syntax suggesting how that should be setup - I'd
rather see some negotiation between client and server determining whether
the bandwidth-saving approach of server fragment retrieval is appropriate
or the server-processing-saving approach of shipping the whole file to the
client and letting it do the work is appropriate. I'd like to see
something more sophisticated than putting it right in the URL, though that
may raise other issues back at the XLink/XPointer corral.
MURATA Makoto then asked two good questions:
Q1. Do we need XPointers for every XML instance?
I personally think that this is too much. For example, I do not think we
have
use XPointers for RDF, which is in the XML syntax.
I think you'll actually see lots of use of XPointers with RDF. Dublin Core
metadata is a prime example where I can see an application only wanting to
grab part of the information (say author and copyright info) without
needing the entire file.
It's easy to make arguments for just about any XML instance, though the
admittedness blurriness between XPointer and a 'real query language'
certainly helps. In general, though, I'd say XPointer fragment identifiers
can be useful with _any_ XML instance.
Q2. Do we need XPointers only for human-readable documents that are
rendered
by some browsers?
I am not sure if the answer is Yes. How do XLL experts in this ML feel?
A number of the people who've been calling for XPointer and XLink plan to
use them in applications where human-readability is not an issue. If you
use an XML document to describe an object structure (nested objects and
properties as elements and attributes, or some variation), you can use
XLink to connect multiple object sets, for instance, and XPointer to
retrieve particular pieces from the set.
XLink and XPointer may also see use in some general modeling cases - it
seems like the WG is trying to make sure this remains possible even though
the 'focus' is hypertext. I'd say XLink and XPointer can go anywhere XML
can go, human-readable or not, browser or custom application.
Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical (July)
Sharing Bandwidth / Cookies
http://www.simonstl.com