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

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

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

-----Original Message-----
[]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 13:46:38 UTC