I've looked through the documents quickly, with an eye for changes
necessary to keep my implementation efforts in line with the drafts.
The present draft is, in one sense, a step backwards. I had been
heartened by the 19990215 version. In contrast to much work in the "XML"
domain, it tended to make a clear distinction between the lexical
expressions for documents and/or queries and the properties of the model
which was the subject of the abstract semantics. This in particular with
respect to names.
The newer version implies that lexical properties retain a central role
in the process of interpreting a query. This where it suggests a
qualified->universal name resolution process as an integral part of type
inference. Or where it admits QName into the type domains in addition to
expanded name.[*]
I suggest that one reconsider this.
a. The previous formulation was straight-forward to implement. Where
dynamic prefix-namespace binding and late name resolution are supported,
the implementation will be much more complex.
b. It is not clear to how to implement late name resolution in a way
which does not undermine the goals for static typing.
c. I've looked for, but not yet found, an example case where late
resolution is necessary. I've made a pass through the new use case
document, to see if someone is proposing an argument for this, but I
found none.
The use-cases and the static typing goal were, as it would happen, the
stimulus for me to remove late name resolution from my present
implementation. It turned out that all resolution could be performed at
the point where the query and/or contributing documents were parsed.
Subsequent to which all operations proceed with universal names.
...
*: The document refers at some times to an "expanded name" and at others
to an "expanded QName." The former term is to be preferred and should be
adopted universally. It better establishes the abstract nature of the
entity and avoids the contradiction which is inherent in the latter.