Re: locator syntax, resources, etc.

"David G. Durand" wrote:
> 
> At 9:29 AM -0700 6/29/99, Paul Prescod wrote:
> >To make this concrete, imagine that you are using XSL or your favorite
> >stylesheet language. You invoke a method called "GetXLinkAnchors()". What
> >do you get back? A list of *what*? I claim that it should be a list of
> >nodes. It should not be possible to claim to link to things that do not
> >have a concept of node because it isn't logically possible to link to
> >something that doesn't have a well-defined concept of identity.
> 
> That is exactly why an operation like GetXLinkAnchors is too limiting to be
> useful. 

What do you propose in exchange? My position is "the application" should
not need to be expert about every media type? If "the application" is (for
example) a link database or RDF property database, it should be able to
track references for media types that it does not "natively" understand.
That implies that we need a plugin that is the equivalent of a "parser"
but for link targets.

A parser returns "nodes" (DOM nodes, grove nodes, etc.) What does a "link
parser" return? That's my fundamental question.

Here's my requirement, given an RDF or XLink annotation database, I need
to be able to "plug in" media handlers so that I can answer questions like
"do these two RDF properties apply to the same node?"

Can you specify an implementation model that supports this and is
implementable for all media types on top of the XLink/XPath/URI/fragment
machinery?

> The problems with foreign anchors, and with spans as currently defined
> simply go away, once you give up the notion of Enumerating anchors, rather
> than the more powerful notion of fetching the document an finding the
> relveant place or places within that document.

It's more powerful but also unimplementable in a manner that scales to
multiple media types and large databases. Given a ten terabyte database
and a request for a "delete this element" operation I do not have the time
to parse every document that COULD POSSIBLY refer to that element. I must
have that list ready in advance.

I tend to consider the primary application of out-of-line XLinks to be
distributed annotation databases. If we implement XLink so that these
databases are impossible to write, then I think that we will have made a
large mistake.

Let's define something concrete and implementable today and extend it to
the weird cases tomorrow. That's the "way of the Web."

> I hope that I'm being a little clearer this time. The only _operational_
> way to resolve a link is to fetch the destination document and then do
> something based on the location within the destination. Note that that
> location (e.g. a span) is not at all the same thing as the Contents of that
> location (e.g. a node or list of nodes). In fact, some locations (like
> spans) lack a well defined notion of contents (at least if your notion of
> content is defined as a node or list of sibling nodes).

I would buy a data model/query model/schema model/API that supported
n-dimensional spans -- as long as we don't give up on the goal of having a
data model/query model/schema model/API that is appropriate to all media
types.

Let me put it this way: there are a variety of places in our information
system (including query languages, schemas languages and APIs) where we
must cross the boundary from one media to another. The result of crossing
that boundary should defined someway. There must be some underlying
concepts that remain the same so that we can understand and implement
these cross-boundary situations in an open, extensible, well-defined
manner.

The most obvious and fundamental concept that must be the same across
media types is the concept of identity. RDF assertions that attach
properties to /FOO and /FOO/. should be equivalent. When and if SMIL and
MPEG have similar concepts, we need to be able to unify them. If they all
have concepts of range and dimension, then we can unify those also.

But please let's not wave away the problem and just make media types black
boxes. If we have to change core applications to support new media types
we might as well give up. We'll drown in the deluge.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

To me programming is more than an important practical art. It is
also a gigantic undertaking in the foundations of knowledge.
	- Grace Hopper

Received on Wednesday, 21 July 1999 11:24:01 UTC