re: Arbortext comments on XPointer requirements

the referenced document required authorization.

> The full proposal can be found at:
>
>   http://www.w3.org/XML/Group/1999/03/ati-xptr-proposal
>
> The following is excerpted and adapted from that proposal.

lacking that, your design principles leave me somewhat perplexed. please note
that our domain is not document processing, but rather the serialization and
manipulation of object models. 

> - The goal of XPointer is to address into documents, which means that the
> primary method of addressing should be to start at the root of the document
> tree.

i have found it a useful aid to program modularization to be able to locate
nodes in a document model in two stages. this requires the ability to address
relative to nodes other than the document root. in our implementation, the
document root is actually a boundary condition.

> - Most intensional addressing (that is, "addressing" of content whose
> current location is likely to be unknown at traversal time) should be
> handled by a query language. It is unreasonable for XPointer to optimize
> for document volatility.

maybe i've missed prior discussion and i'm stumbling over terminology, but i
don't see how it is possible to "[address] content whose current location is
likely to be unknown". is there some issue here distinguishing between 'child'
and 'descendant' references?

>
> - The target of addressing should be single objects. It is reasonable to
> address ranges that may correspond to user selections, but this
> functionality should have single-node addressing at its base.

we have found it essential to be able to name all nodes which meet some
criteria as a precondition for processing. at least all in a given individual
node's content. we have found it useful to have a similarly succinct name for
all nodes meeting some criteria in a given tree. this has been the case both
for serialization and for dom processing.

if, on the other hand, the target of this remark is the amorphous result type
of 'span' references, i agree with it. we have, for example, implemented
support for xptr references as setf'able CLOS storage locations. under which
circumstance the amorphous type of a 'span' reference represents a significant
impedement to a complete implementation.

nb. in general, one may argue that we need a query language instead of xptr,
but, from my reading of the xsl pattern spec and the xql spec, we'de just map
those parts of each of those which we need onto the same underlying
representation as we've found sufficient for xptr....

Received on Sunday, 11 April 1999 13:25:41 UTC