ACTION-741:Summarize schema issues with Verification elements

This is a companion to http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0046.html so please read that first.

What I was proposing on the last call was to consider revising the XML model of the Verification child elements to match the conventions elsewhere in the specification in which a generic element with an Algorithm or Type attribute is used to identify specific versions of the generic element.

Today, we have this:

<dsig2:Selection Type="..." Subtype="...">
	...
</dsig2:Selection>
<dsig2:Verificiation>
    <dsig2:DigestDataLength>100</dsig2:DigestDataLength>
    <dsig2:IDAttributes>
        <dsig2:QualifiedAttr Name="type" NS="http://www.w3.org/2001/XMLSchema-instance"/>
    </dsig2:IDAttributes>
</dsig2:Verification>

In the linked email, I'm suggesting this:

<dsig2:Selection Algorithm="...">
	...
</dsig2:Selection>

Here, I'm suggesting this:

<dsig2:Verifications>
    <dsig2:Verification Type="...#DigestDataLength">100</dsig2:Verification>
    <dsig2:Verification Type="...#IDAttributes">
        <dsig2:QualifiedAttr Name="type" NS="http://www.w3.org/2001/XMLSchema-instance"/>
    </dsig2:Verification>
</dsig2:Verifications>

There would be some schema and section reorg associated with this change, largely analagous to the changes I suggested in the linked email, so I don't think I need to go through all of them.

Note that I am not suggesting this is "better" in XML or anything like that. I'm suggesting it's more *consistent* with the rest of the spec. For better or worse, decisions get made and different specs take different approaches to representing extensibility. I think consistency within a spec is the important issue. It makes it easier to build implementations when you aren't constantly mixing XML metaphors. IMHO at least.

-- Scott

Received on Friday, 10 December 2010 19:29:12 UTC