Re: Con Call and XPointer/XPath

At 14:37 99/09/09 -0700, John Boyer wrote:
 >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.

We also have a requirement to fit the following dead-lines if possible:

        Nov 99 XML Signature Syntax and Processing document to 
        Last Call for Proposed Recommendation / Proposed Standard RFC 

        Dec 99 Signature Semantics document to Last Call for 
        NOTE / Informational RFC 

        http://www.w3.org/Signature/charter-19990624.html

If successful, the core syntax might even match or come in under XPtr in
terms of time. Regardless, I am not dismissing the requirement that our
deliverables permit selective signing. However, I don't think that is the
same as saying it is a mandatory to implement for all "core syntax"
applications. If it happens great, but I think we should err on the side of
timeliness. Given the "signature semantics" document has become the
"manifest/package" document in my mind, it will also be a standards track
document, though probably a bit slower.

 >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

I don't know what "optics" means, but the two issues here are (1) timeliness
and spec dependency immaturity and (2) application requirements regarding
processing/memory requirements. It is not stated in the RD, but people have
stated they may do signatures in a smart-card type form factor. Again, it
isn't in the RD, so I don't feel too constrained by it, but I'm always for
defaulting to simplicity and being shown it can be easily done 

 >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.

I've been arguing that this requirement be removed from implementation in
the core syntax until it can be demonstrated that it can be advanced at the
same rate as the rest of that spec. I am now quite convinced that the best
way to meet the requirement (wherever and whenever) is with XPtr.

 >4) Contrary to a con call assertion made before I joined the call (at the
 >end), XPointer is NOT TIED TO DOM. 

Agreed in principle:

   6. Conformance
   A string conforms to XPointer if it adheres to the syntactic
   requirements imposed by this specification (including that part of
   XPath included by reference). Note that this does not require that the
   string, in association with a URI, actually point to a resource that
   exists at any given moment.

   http://www.w3.org/TR/WD-xptr
   
But still not sure. In speaking with Dan Connolly, he seemed to agree that
the implicit InfoSet c14n was unavoidable, but understood your point and
raised the example of:

        <!DOCTYPE root [ <!ENTITY anElt "<e/>"> ]>
<root>&anElt;&anElt;&anElt;</root>

        And an xpointer that picks the second child of the root element. 
        What sequence of bytes does that correspond to from the input?

In investigating which spec defines what is returned to a client when an
Xlink+XPtr is invoked, I end up with

        5.3.1 / (root) Locates the entire resource; not the document
element, but the 
        parent which is over it as well as any adjacent processing
instructions and/or 
        other nodes permitted by XML.

        http://www.w3.org/1999/07/WD-xptr-19990709 


        infoset: 2.1. The Document Information Item
        There is always one document information item in the information
set, and 
        all other information items are related to the document information
item, either 
        directly or indirectly.

        http://www.w3.org/TR/1999/WD-xml-infoset-19990517 

So I'm still not quite sure if this is well
understood/defined/specified/standardized such that it be an integral part
of XML signature at this time. I'd be interested in your answer to the
question, or for Dan to comment further.

 >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).

Meaning we'd have 

1. the x-path relative axes: {child, descendent, descendent-or-self, parent,
ancestor, ancestor-or-self, preceding-sibling, following-sibling, preceding,
following, self, attribute}
2. the x-path code tests: {Qnames, text(), comment(), pi()}
3. the x-path positional tests: {position, last, <,>}

but not

1. the x-ptr axes: {range, string}
2. the x-ptr absolute location paths: {/(root), id, here, origin}

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Friday, 10 September 1999 18:23:01 UTC