W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

Re: XPath transform

From: TAMURA Kent <kent@trl.ibm.co.jp>
Date: Wed, 26 Jan 2000 15:06:31 +0900
Message-Id: <200001260606.PAA41204@ns.trl.ibm.com>
To: <w3c-ietf-xmldsig@w3.org>

In message "RE: XPath transform"
    on 00/01/24, "John Boyer" <jboyer@uwi.com> writes:
> 4) Questions.
> a) Would you agree that we should use c14n post-processing even though this
> constrains XPath results more than you may have previously believed?  If so,
> it is most likely that it will be changed.

I agree.

> b) Would you agree that it is sufficient for us to simply recommend against
> use of Xpath functions that rely on an order for the attribute axis?

I agree.

> c) Would you agree that we should retain the c14n preprocessing for the
> reasons I described above?

(See below)


> 2) I was not attempting "arrogation" in defining the behavior of XSLT
> implementations.  I asked you a question, which you didn't answer.  The
> question was:  For any XPath expression E that yields a node-set which
> includes attributes, what is the character result of the XPath expression
> string(E) under your given XSLT implementation?  More importantly, whether
> the XPath people like it or not, it is a bug in their specification when two
> applications that follow the "specification" yield different results for
> string(E).  It is not arrogance to point out that because a specification
> has a bug in it, not all compliant software will be usable.  Procrustean
> perhaps, but not arrogant.

I have looked into attribute orders of LotusXSL 0.19.2 [1] and
XT[2]+omquery[3] in these two days.  Both of them do not change
the input order of attribute, which is indicated by
element.getAttributes().item(unsigned long index) in the DOM. 

The "string(E)" returns the attribute value of the first

Ok, I have understood you think the XPath specification has

[1] http://www.alphaworks.ibm.com/tech/LotusXSL
[2] http://www.jclark.com/xml/xt.html
[3] http://www.246.ne.jp/~kamiya/pub/XPath4XT.html

> Note 3:  Despite not solving the attribute order problem, the c14n
> preprocessing is still useful for the following reasons:  a) By using c14n,
> we at least guarantee that the encoding is UTF-8, so we will not need to
> figure out a way to affix a byte order to the XPath output (if the output
> were UTF-16, then the c14n algorithm would need this).  b) Attribute value
> normalizations are done in a consistent way. c) We reap all of the benefits
> of the minimal canonicalization.

a) Does this mean the character encoding for XPath output other
than node-set should be the same as character encoding of the
input XML document?  Why?

b) XML processors do attribute value normalization.  It is done
while parsing before constructing SAX events or a DOM tree.

TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Wednesday, 26 January 2000 01:07:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC