Draft 04-January-2000: Algorithm/Transform/Parameter

As I read through the latest draft, I found some inconsistencies 
regarding the content models of algorithm identifiers, like
CanonicalizationMethod or SignatureMethod, and Transform.

My interpretation so far has been as follows: 

    Both all algorithm identifiers (elements CanonicalizationMethod, 
    SignatureMethod, DigestMethod) and the Transform element share
    a common content model which equals to following DTD snippets:

    <!ELEMENT SignatureMethod Parameter* >
    <!ELEMENT DigestMethod Parameter* >
    <!ELEMENT CanonicalizationMethod Parameter* >
    <!ELEMENT Transform Parameter* >

    This allows the core to deal with arbitrary algorithms and transforms
    without having to know any details about the parameters of them. The
    core simply passes on a list of Parameters, whereas the order of the
    list is given by the document order of the XML document.

Now that I have carefully re-read the draft, I am not sure if my 
interpretation is right.

On the one hand most of the Schema and DTD definitions support my
assumption, such as those in sections

    - 3.3.1 (CanonicalizationMethod)
    - 3.3.2 (SignatureMethod)
    - 3.3.3.2 (DigestMethod)
    - 3.3.3.1 (Transform, only Schema)

Additionally I have found the following sentence in section 3.3.3.1:

    "Each Transform consists of an Algorithm attribute, optional Type and
     Charset attributes, and content parameters, if any, appropriate for 
     the given algorithm."

On the other hand there are some other parts of the draft, which 
contradict my interpretation:

    - section 3.3.3.1: DTD for Transform element has content model 'ANY'

    - section 5.1, last two sentences of first paragraph:

        "Explicit additional parameters to an algorithm appear as content 
         elements within the algorithm role element. Such parameter
         elements have a descriptive element name, which is frequently 
         algorithm specific, and MUST be in an algorithm specific namespace."

    - section 5.3, code example for SignatureMethod:

	<SignatureMethod Algorithm="&dsig;/hmac-sha1"> 
	  <hmac-outputlength xmlns="&dsig;/hmac-sha1"> 
	     128 
	  </hmac-outputlength> 
	</SignatureMethod>

    - section 5.6.3, first sentence:

        "The Transform element content MUST conform to the XML Path Language 
         [XPath] syntax."

    - section 5.6.4, first sentence:

        "The Transform element content MUST conform to the XML Pointer
         Language [XPointer] syntax."

    - section 5.6.5, first sentence:

        "The Transform element content MUST conform to the XSL Transforms 
         [XSLT] language syntax."

In spite of these contradictions I think that my interpretation has a
lot of advantages because of its generic approach.

I would be pleased to hear any comments on that topic, especially if there
are arguments against my interpretation.

Gregor
-- 
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------