Re: Con Call and XPointer/XPath

It's too bad I missed much of this (9sep99) con call as it seems there was
some consensus building on punting Xptr out of the core syntax and/or making
it optional, and these possible decisions concern me greatly for the
following reasons:

Summary
=======
1) Requirements, by definition, are not optional
2) Bad optics for W3C
3) Bad optics for DSig WG
4) XPointer is NOT TIED TO DOM
5) XPointer/XPath provides easy syntax for specifying partial documents
	esp. for saying what *not* to sign as opposed to saying what to sign
6) Simplified subset of XPath can solve all problems.

Details
=======
1) We should not relegate XPointer support to the manifest only, nor should
we make XPointer 'optional' in the core syntax.  The reason is that we have
a *requirement* to sign partial documents, and we have an implicit
*requirement* to create secure digital signatures.  Requirements, by
definition, are not optional.

2) The optics for the W3C as a standards body are poor when a W3C work such
as XPointer is dismissed as being too complicated for use in other W3C
standards works such as DSig, esp. when at least one WG participant has
shown a clear and as yet unrefuted need for (something like) the former
standard in order to meet the requirements of the latter.  What is the point
of building the former spec if it is far too complicated (whick I don't
believe), and what is the point of building the latter spec if it cannot
adequately address the problem space (which I still maintain it cannot do
without requirement for XPointer)?

3) Also as a matter of optics, the DSig WG cannot be perceived as not
wanting to require enough code to create truly secure XML signatures, esp.
when we are talking about whether to implement such well known constructs as
boolean logical operators and comparators as the basis of filtering
elements.

4) Contrary to a con call assertion made before I joined the call (at the
end), XPointer is NOT TIED TO DOM.  DOM is only mentioned in Xptr to state
that the 'range' command is like the one in DOM; interestingly we do not
seem to need the range command or anything specific to Xptr, so the mention
of DOM is irrelevant.  DOM is only mentioned in XPath to explain why some
axis has a particular name.  Nowhere does it state that XPtr and XPath are
tied to anything but the XML 1.0 spec, to which all XML parsers must comply.

Naturally, some form of XML parser will come into the picture here because
you need it in order to make heads or tails of ANY partial document
processing scheme.  For example, you cannot select objects by URI fragment
without parsing the document enough to find the elements indicated by the
fragment ID (and also figuring out which attribute is supposed to represent
the ID in the first place).

XPtr is just a syntax for describing how to filter a document.  With a
simple BNF rewrite rule, one can construct a hand-built recursive descent
parser to recognize the XPtr syntax, so a recognizer can be built by a
language newcomer despite the left associativity of boolean operators.  Once
you can parse the Xptr itself, how you choose to apply it to the document
depends strictly on the rules of XML 1.0 plus whatever you've been passed by
the previous transform step of the digital signature transformation
sequence.

5) Xptr (or some subset of it) can be easily be used to indicate the
portions of the document that must be signed.  More importantly, Xptr
provides an easy syntax for describing which portions of the document should
*not* be signed.  This is very important since it is useful in the creation
of secure signatures to have the message M that is actually signed *be* a
full XML document including all 'ancestor' information for the elements of
interest, including the encoding information, the DTD, the tags and
attributes of all ancestor elements, the order of sibling elements and even
PIs and comments if necessary to a particular signature (e.g. to sign code
expressed in XML).

6) Even if the whole of Xptr is more than is necessary, it should be
possible for us to mete out a subset that can still accomplish what is
required.  For instance, we do not need anything in Xptr itself, but rather
some of the contents of XPath.  Further, we could consider throwing out
recognition of syntactic variations (the syntax sugar, so to speak).

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

Received on Thursday, 9 September 1999 17:39:11 UTC