- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 22 Jul 1999 15:52:16 -0400
- To: "David G. Durand" <david@dynamicdiagrams.com>, Paul Prescod <paul@prescod.net>, Paul Grosso <pgrosso@arbortext.com>
- Cc: w3c-xml-linking-ig@w3.org, www-rdf-comments@w3.org, www-wca@w3.org
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