Re: NEED FEEDBACK TODAY RE: Comments for Transform

Our XPath thing differs some from the XPath spec.  Perhaps it should
be called DSigXPath.  Since document order is a well defined concept
in XPath, I don't see why we can't specify that for attributes and
namespaces in DSigXPath if we want even if XPath doesn't.  But I also
continue to believe that most implementations will use DOM or, for the
resource constrained case, SAX.  Even SAX assumes that, while the
device might have problems manipulating the entire docment in memory,
it can always hold all the attributes, etc., from a tag.  So, my
inclination is to go with the canonicalization order since SAX or
DOM can scramble the order so you have to re-order in a canonical
fashion.

Thanks,
Donald

From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Thu, 9 Dec 1999 13:47:38 -0500 (EST)
Resent-Message-Id:  <199912091847.NAA18537@www19.w3.org>
To:  "TAMURA Kent" <kent@trl.ibm.co.jp>, <w3c-ietf-xmldsig@w3.org>
Cc:  "Joseph M. Reagle Jr." <reagle@w3.org>,
            "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            "Dave Solo" <dsolo@alum.mit.edu>, "Ed Simon" <ed.simon@entrust.com>
Date:  Thu, 9 Dec 1999 10:45:17 -0800
Message-ID:  <NDBBLAOMJKOFPMBCHJOIMEKDCCAA.jboyer@uwi.com>

>Document order is, in fact, defined in XPath.  The XPath spec says that
>attribute and namespace nodes are in application dependent order, and within
>the DSig application of XPath, the XPath Transform section defined that
>order to be document order.
>
>In the telecon this morning, I only had a minute to read the emails before
>the call, and so I didn't remember at the time why I had selected document
>order for attributes and namespaces.  I now recall that we had some feedback
>that low-resource environments could, perhaps, respond more efficiently with
>document order since it would be possible to react to the XML document as a
>stream of bytes rather than having to put it through an XML processor on a
>low-resource device.  The programming on the device could be quite specific
>to the application, and hence probably quite small.
>
>The main thing I need feedback on is whether document order is too
>inconvenient for the majority of uses.  I know that a number of APIs tend to
>put attributes in alphabetic order, and I do not know whether the document
>order is recoverable (I don't think it is).
>
>I need to know this before we decide to change the XPath transform section
>to impose a different order.  The only other reasonable order seems to be
>the order defined in the c14n spec [1].  Naturally, if the input to XPath is
>canonicalized, then this is the same as document order, but for
>uncanonicalized documents, this order would have to be imposed by the
>(recommended) core behavior as part of interpreting the XPath.
>
>[1] http://www.w3.org/TR/xml-c14n#sec-namespaces
>
>Unfortunately, this decision implies non-local changes since namespace
>propogate down to descendants that actually use them.  The non-local changes
>are what lead me to select document order.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>
>
>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of TAMURA Kent
>Sent: Thursday, December 09, 1999 12:39 AM
>To: John Boyer; w3c-ietf-xmldsig@w3.org
>Cc: Dave Solo
>Subject: Re: Comments for Transform
>
>
>
>In message "RE: Comments for Transform"
>    on 99/12/07, "John Boyer" <jboyer@uwi.com> writes:
>> Step #3 states that the node-set will be interpreted in document order,
>> which is clearly defined in the XPath specification [1].
>>
>> [1] http://www.w3.org/TR/xpath#dt-document-order
>
>No.  Order in a set of attribute nodes or namespace nodes is
>implementation-dependent.
>
>In http://www.w3.org/TR/xpath#dt-document-order
>	....  The relative order of namespace nodes is
>	implementation-dependent. The relative order of
>	attribute nodes is implementation-dependent. Reverse
>	document order is the reverse of document order.
>
>--
>TAMURA Kent @ Tokyo Research Laboratory, IBM
>

Received on Thursday, 9 December 1999 15:16:02 UTC