Re: Suggested additions to 3.0 Processing Rules section

At 06:11 7/12/2001, merlin wrote:
>It is not clear to me whether a schema-validated document is
>required to expose both the initial value (i.e., post-DTD)
>and the schema-normalized value, or whether it can expose just
>the schema-normalized value. But schema validation may
>introduce a set of normalization problems with signed docs.

I wanted to draft some text on this issue, but backed off and only included 
[1]:
>Transforms can include operations such as canonicalization, 
>encoding/decoding (including compression/inflation), XSLT, XPath,  /+XML 
>Schema validation, or XInclude.+/


[1] 
http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-o-Reference
$Revision: 1.94 $ on $Date: 2001/07/16 17:28:08 $


I thought I'd include two small sections (a paragraph each) in section 6.6 
for XML Schema and XInclude, but then I wondered if we needed to parametize 
them -- also we recommend all the transforms in this section, and I would 
consider these optional.

Presently, XML Signature doesn't really look at the XML itself for 
direction, but only at the series of Transforms. But the way I conceived of 
XML Schema and XInclude is that's a directive to actually process the 
document based on internal info. In XInclude's cases, that's essential as 
it'd be very difficult to parameterize how to do the XIncludes outside of 
the document. But in schema's case, should the Transforms be able to specify 
the schema used to validate it? What happens if there's a local schema and a 
parameterized schema specified?

   <Signature> ... <!-- Over Foo -->
     <Transform Algorithm="&schema;">
       <schema>...</schema>
   __

   <Foo Id="MyFirstFoo" xmlns="http://www.w3.org/2000/09/foo"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.w3.org/2000/09/foo
      foo-schema.xsd">

We could continue to leave this up to the application to figure out and not 
do anything.

Or we could try to clarify our model a bit. My preference is to keep it 
simple and not have these be parametrized, but this also begs the question 
with respect to XSLT whereby we can instantiate an in-line schema (content 
of the transform element) but can't invoke one that might be rather large 
(and easier to identify with a URI -- which one should sign for security) 
nor do we have a way to process the XSLTs within the document isetlf (e.g., 
[2]).

[2] http://www.w3.org/TR/xslt#result-element-stylesheet

Consequently, I'd propose that

1. the following algorithm URIs actually invoke that application on the 
document itself:
         http://www.w3.org/TR/1999/REC-xslt-19991116
         http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
         http://www.w3.org/TR/2001/WD-xinclude-20010516
2. If you want to parametarize, include another transform with the parameter.
3. ?(We specify a <Transform URI="foo" Location="bar"/> that can identify 
the location of the schema, XSLT, or whatnot)? [I hesitate because this 
seems like a substantive addition.]

So, in the following example:

   <Signature> ...
     <Transform 
Algorithm="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">
     <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116"/>
     <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116"/>
         <xsl:stylesheet ...></xsl:stylesheet>
     <Transform Algorithm="http://www.w3.org/TR/2001/WD-xinclude-20010516"/>
     ...

One validates the schema according to any declarations within the document; 
then applies XSLT to any declarations in the document; then XSLT using the 
signature-inline stylesheet, then expand all XIncludes.



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

Received on Monday, 16 July 2001 14:06:14 UTC