support for shorthand (barename) pointers : summary of discussion at f2f

During the last conf call we discussed bug# 5543 (SML URI seems overconstrained). This bug was discussed at length during the recent f2f (3/31/08). We did not remember the details of that discussion during the conf call. I volunteered to send a summary of this discussion as a part of AI# 181. I have provided information based on the f2f minutes (http://lists.w3.org/Archives/Public/public-sml/2008Apr/att-0040/20080331-sml-minutes.html). I also filled in some info that would be useful but was not captured by the scribe.

The xpointer framework defines the semantics of shorthand pointers at: http://www.w3.org/TR/xptr-framework/#shorthand

Here are the salient details of the discussion during f2f.


1.    A shorthand pointer is denoted using a single NCNAME in the fragment part. For example, http://foo/bar.xml#zoo.

2.    The identifiers can be defined by DTD, schema or arbitrary application-specific logic.

3.    Identifying the target of a shorthand pointer requires dtd processing and schema validation (PSVI).

4.    Given the name of the ID attribute (say @barId), '#foo' can be rewritten as smlxpath1('//*[@barId = 'foo']). This obviously does not work when we do not know the name of the ID attribute(s).

5.    Another way to achieve the same thing would be smlxpath1("id('foo')=.")

6.    Absent very complete knowledge of the vocabulary being processed, there is no reliable way to deterministically transform from barename to an xpath expression. This is because two attributes (fooID and barID) can be derived from ID. The xpath predicate would have to choose between fooID and barID, but it has no way to know this up front.

7.    The xpointer framework spec itself notes that: "An element information item might be identified by multiple values, in a document with more than one of DTD-determined IDs, schema-determined IDs, and externally-determined IDs. In such documents, a loss of interoperability might result if the identifier values for a particular element are not always the same."

8.    We want deref to be usable outside of a validation context.

9.    SML URI scheme is written with interoperability in mind. This is a reason not to allow it in that scheme. One could always use shorthand pointers in other SML ref schemes.


As seen from the notes above, there are 2 main problems with supporting shorthand pointers in the SML URI scheme:

1.    We took great care in writing the spec such that finding the target of a ref (at least the one that uses SML URI scheme) does not need schema validation. This is why we have defined extra behavior of deref() outside the context of model validation. Supporting shorthand pointers will mean that we cannot do that anymore.

2.    A shorthand pointer ID can be defined using arbitrary app specific logic. This works against inter-operability.