RE: XSL Transform

Here are my reasons for being precise as to how XSLT transforms should be
specified in an XML Signature.  Apologies for sounding elementary but I
want to start from the basics.

1.  It is generally accepted that applying one or more transforms to an
XML instance and signing the result makes sense for a lot of applications;
that is why we have <Transforms> element.

2.  The popular acceptance of XSLT in the general XML community will make 
it a popular choice for doing transformations within XML Signatures.

3.  We want to make it easy for implmentors of the XML Signature spec to
handle XSLT and we want to make sure that apps that create XML Signatures
do so in as consistent a way as possible so that they are as interoperable
as possible.

4.  There is no reason why an XSLT transform in an XML Signature should not
have a root element of 
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform">
and contain complete, valid XSLT stylesheets.

5.  Schemas allow us to enforce point 4.  Enforcing point 4 will make it
that
much easier to achieve point 3.

The problem with the <any> element is that even if the namespace attribute
is "http://www.w3.org/1999/XSL/Transform", it does not
enforce that the child element is <stylesheet> so it could be quite possible
to have

<Transform>
<xsl:template xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
match="*[@signThis='yes']">
<xsl:copy ... />
</xsl:template>
</Transform>

instead of the correct form shown here

<Transform>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ...>
...
<xsl:template match="*[@signThis='yes']">
<xsl:copy ... />
</xsl:template>
</xsl:stylesheet>
</Transform>

Basically, I don't want to have XML Signatures validate against a schema if
a 
<Transform> element contains only a vestigial XSLT stylesheet.  With XSLT,
we 
can be precise as to what the <Transform> element should look like, and
doing so 
will make things go more smoothly for implementors and interoperability.

Note:  The above assumes that a schema's <any> element is a wildcard for 
any element within the specified namespace, not necessarily the root
element.  
I'm also assuming schemas  allow one to specify a particular element in a 
particular namespace. Please correct me if I'm wrong about these; I haven't 
had the chance to read the schema spec recently.

Merlin, is this along the lines of the way you were thinking.

Ed
-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Tuesday, July 25, 2000 7:34 PM
To: Ed Simon; Merlin Hughes
Cc: w3c-ietf-xmldsig@w3.org; ht@cogsci.ed.ac.uk
Subject: RE: XSL Transform


At 09:16 7/25/2000 -0400, Ed Simon wrote:
 >I agree with Merlin.  

But <any\> already is an option.

 >   xmlns:xsl=""> <!--  NEW  -->

(You forgot the namespace "http://www.w3.org/1999/XSL/Transform"! <smile>)

Regardless, we might as well just remove the XSLT element (since it has its
own xsl:stylesheet element) and include a comment:

   <element name='Transform'> 
     <complexType content='mixed'>
       <choice minOccurs='1' maxOccurs='unbounded'> 
         <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
 !       <!-- Including well formed XSLT elements -->
         <element name='XPath' type='string'/> 
       </choice>
       <attribute name='Algorithm' type='uriReference' use='required'/> 
     </complexType>
   </element>

You could do the following but I don't see any reason to since it's
redundant.

   <element name='Transform'> 
     <complexType content='mixed'>
       <choice minOccurs='1' maxOccurs='unbounded'> 
         <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
!        <any namespace="http://www.w3.org/1999/XSL/Transform"/>
         <element name='XPath' type='string'/> 
       </choice>
       <attribute name='Algorithm' type='uriReference' use='required'/> 
     </complexType>
   </element>


_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 25 July 2000 17:31:43 UTC