RE: XPath transform

Hi Kent,

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

<John>Good.</John>

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

<John>Good.</John>

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

(See below)

<John>See below.</John>

	--------------------------------

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

Ok, I have understood you think the XPath specification has
bugs.

<John>
Ok, thanks.  Now, I may be reading this wrong, but you're saying it doesn't
change the input order.  Do you mean that the the attributes are retained in
the order they originally appeared in the document?  In other words, if the
file on disk contained

<E attz="1" atty="2" attx="3"/>

then the string resulting from string(E) will be

<E attz="1" atty="2" attx="3"/>

despite the fact that the order of the attributes *would be* different if
they were sorted into alphabetic order?

Thanks in advance for testing this.
</John>

[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?

<John>
No, (so I think we agree).  The postprocess c14n will standardize on UTF-8.
What I was referring to is that the result of the XPath expression, which is
fed into the postprocess c14n, is only guaranteed to be UTF-8 if we c14n
preprocess.  If we do not c14n preprocess, then the result of the XPath
expression may be in UTF-16.  If it is, then it will need a byte order mark
before we pass it to the c14n postprocess.

Do you agree with that?
</John>

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

<John>
Yes, attribute normalization is done, but the exact rules can vary for some
attributes based on whether the XML processor is a validating or
non-validating processor.  The c14n preprocess guarantees that the actions
associated with a validating processor are performed in all cases.

Given these clarifications, do you agree that c14n preprocess is still
required?

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

</John>

--
TAMURA Kent @ Tokyo Research Laboratory, IBM

Received on Wednesday, 26 January 2000 13:03:31 UTC