Re: locator syntax, resources, etc.

At 10:38 AM 7/19/99 -0700, David G. Durand wrote:
>
>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).
>

David,

You are being clear enough so I suspect I agree with you a lot.  But I
think you have to be more orthodox here to establish credibility with those
not necessarily predisposed to sympathy.

If you can't define the content of a span, then there isn's a span that one
can point to.  A span is an unmarked object; it is a collector in the
content domain that is well-posed as to its content but not identified in
the markup as an entity.

I believe that when we have the caracter model which is safe for
international use and the canonicalization practice normalized, we will
indeed have a model where a span is synonymous (reliably and
bidirectionally interchangeable) with a collection of sub-objects, albeit
some of the sub-objects are anonymous in the structure identified by the
markup.

At the higher level, I think what people need to understand is that in
functional terms the proper generalization of pointer is query, and not
locator.  This is "extension equivalent" to the way you described it being
applied.

Note that the thinking behind the URI syntax RFC includes the idea that the
interpretation of #fragment contents is dependent on the type of the
retrieved resource.  There is an implied order of binding.  Retrieving the
resource binds some things and with those bound one is then able to
interpret #fragment as a key.  But not until the resource is "retrieved"
and its type determined for sure.

The buried question here is whether #fragment in any XML application should
be limited to semantics that apply to _every_ XML application.  This is a
policy decision in the domain of XML applications.  If this debate has been
joined in those terms, I missed it.

Since I believe that there should be a) XML-generic ways to adduce
semantics above and beyond syntactic declarations in the usage of
particular applications, and b) certain minimum or nominal expectations on
all XML applications [requirements on orientation and navigation
infrastructure for access in eyes-free mode are in this class] for
asserting and providing a minimum level of standard semantics, I _do not_
believe that X-pointer should be limited in its query semantics to things
that are obvious from the syntax alone.

So the long range plan (and incremental steps) should protect the potential
for #fragment or X-pointer to grow to encompass arbitrary queries which are
well-posed in the proper schema of a given XML application profile.  Thus
the functional requirements for X-pointer are established in the context of
a multilevel-partial-understanding view of the Web architecture, not a
syntactic, constructivist view thereof.  Both views have to work together.
We are running into trouble because we try to extend the construction
without having come to consensus on the objectives and scope of
_understanding_ functionality, layering, and architecture.

Al

Received on Thursday, 22 July 1999 16:00:13 UTC