RE: XSLT

I think the question to ask is
"Given a result tree, is it possible to correctly write out
two different XML streams such that the canonicalized form
of the streams are different?"

If the W3C (including ourselves) have done things right, the answer
should be 
"No.  A result tree has only one canonical form associated with it."  
(Admittedly, I'd like to think more about
this question but my standards time is kind of pre-occupied on 
the encryption front right now.)

Just like the IETF interop testing uncovered some subtle parser
nuances that need refinement, I expect there will be similar
discoveries with XSLT tools.

Let's face it, because digital signatures must be absolutely 100%
unforgiving to any discrepancy (as they must be), bringing digital 
signatures to the world of XML will be a very effective way of 
flushing out bugs in both XML-related specs and the tools built on 
those specs.  Ultimately, that's good for everyone.

Ed
-----Original Message-----
From: John Boyer [mailto:jboyer@PureEdge.com]
Sent: Friday, August 18, 2000 1:47 PM
To: Martin J. Duerst; XML DSig
Subject: RE: XSLT


Hi Martin and Ed,

Actually, Martin, I do think DSig has some responsibility to document I18N
limitations of this transform, so we could really use your help on that.

However, I was more concerned with generic stuff like the fact that when I
set my XSLT processor to output text/html, it tends to rewrite some stuff on
me like line breaks and non-minimal minimalized attributes.  I don't
'serialize the result tree' tree directly as Ed recommends.

So, I'm fishing for some kind of statement that when an XSLT processor is
set to output text/xml, that these funny rewrite rules aren't applied to my
output.

As long as that's true, then a c14n transform after the XSLT should clean up
the mess; I just want some additional assurance as we approach CR that we
aren't messing this up. (And, again, thanks for your patience, Ed).

Sincerely,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Martin J. Duerst
Sent: Thursday, August 17, 2000 7:54 PM
To: John Boyer; XML DSig
Subject: Re: XSLT


At 00/08/17 12:30 -0700, John Boyer wrote:
>I've often wondered, how open-ended is XSLT regarding the output.
>
>Are there permissible implementation differences that are not covered off
>by throwing a c14n transform after (or before and after)?

There are definitely things that fall in this category, in particular
in the area of localization. For example you can say that you want
some items sorted, and can indicate that the sort order should
be according to e.g. Swedish practices, but you are not guaranteed
that your processor knows Swedish sorting, nor are you sure that
all processors do exactly the same for Swedish even if they know it.

This is I guess quite a bit away from your main problem.

Regards,   Martin.


>Or rather, is there an XSLT conformance mode that guarantees any
>implementation adhering to that mode produces the exact same output
>(except possibly for differences that can be corrected by c14n, and
>possibly only if the input is canonicalized)?
>
>Or is it the case, for example, that random extra whitespace may be added
>outside of start tags by some processors and not by others?
>

Received on Friday, 18 August 2000 14:49:17 UTC