This document describes possible editorial conventions used throughout the core specification. Letters are used to designate steps or categories, numbers are used to designate options the WG should choose.
Do people prefer Element Names as:
<DigestAlgorithm>...</DigestAlgorithm>
<DigestValue>...</DigestValue>
<Digest>
<Algorithm>
<Value>
</Digest>
If people prefer #2, we can change SignatureValue to SignatureResult since it is a special case.
There are three ways to express semantics, via explicit representation in the XML syntax, a default declaration in the DTD, or via the natural language in the specification. Do people prefer:
Properties:
(Consequently) If you need to nest other content in an element, it must not contain the term Value or Algorithm in its name.
<Signature
xmlns="http://www.w3.org/1999/10/signature-core">
<SignedInfo>
<CanonicalizationAlgorithm>null</CanonicalizationAlgorithm>
<SignatureAlgorithm>urn:ietf:dsaWithSHA-1</SignatureAlgorithm>
<ObjectReference HREF="http://www.iet.org"/>
<Type>text/html;
charset="us-ascii"</Type>
<DigestValue Algorithm="urn:ietf:sha-1"
Encoding="urn:ietf:base64">ab3234c34</DigestValue>
</ObjectReference>
</SignedInfo>
<SignatureValue Encoding="urn:ietf:base64">ab3234c34</SignatureValue>
<KeyInfo>
<keyname>Solo</keyname>
</keyinfo>
</Signature>
The following letters designated classes of syntax structures for which we want conventions. The numbers represent potential options the WG should select.
<Foo><Parameter type="urn:...">1</Parameter></Foo>
<Foo><Parameter>
<Type>urn:...</Type>
<Value>1</Value>
</Parameter></Foo>
<Foo><Parameter type="urn:..." encoding="urn:...">93kv0w=</Parameter></Foo>
<Foo><Parameter><Type>urn:...</Type>
<Encoding>urn:...</Encoding><Value>93kv0w=</Value>
</Parameter></Foo>
<Signature><Value encoding="urn:...">...</Value></Signature>
<Signature><Encoding>urn:...</Encoding><Value>...</Value></Signature>
If there are cases where an algorithm has both parameters and a value, which I think is reasonable, this argues against B.1 and D.1.
Eastlake comments:
1. Reserve use of quoted-attributes for HREFs, identifiers, namespaces, and xlinks.
<Signature Id="1" xmlsn="http://www.w3.org/1999/10/signature-core">
2. Simple name/value pairs that describe something then use an element with content
<Digest>
<Algorithm>dsig:sha-1</Algorithm>
<Encoding>dsig:base64</Endoding>
<Value>ab3234c34</Value>
</Digest>
3. If a name/value pair needs to be further qualified, or you want its content model to be open, then do not use its content for a value.
<Algorithm>
<Parameter>
<Type>blah</Type>
<Value>34</Value>
</Parameter>
<Value>urn:ietf:sha-1</Value>
</Algorithm>
The resulting syntax under these productions is (notice the ObjectReference HREF):
<Signature
xmlns="http://www.w3.org/1999/10/signature-core">
<SignedInfo>
<CanonicalizationAlgorithm>null</CanonicalizationAlgorithm>
<SignatureAlgorithm>urn:ietf:dsaWithSHA-1</SignatureAlgorithm>
<ObjectReference
HREF="http://www.iet.org"/>
<Type>text/html;
charset="us-ascii"</Type>
<Digest>
<Algorithm>urn:ietf:sha-1</Algorithm>
<Encoding>urn:ietf:base64</Endoding>
<Value>ab3234c34</Value>
</Digest>
</ObjectReference>
</SignedInfo>
<SignatureValue>
<Encoding>urn:ietf:base64</Endoding>
<Value>ab3234c34</Value>
</SignatureValue>
<KeyInfo>
<keyname>Solo</keyname>
</keyinfo>
</Signature>
It results in slightly more verbose syntax, that might be alleviated by an exception to rule 1: "However, if you only have one value/name pair that you wish to associate with an element, you may place it as a quoted-attribute&value" but I was trying to be very clean above.
Anything that is likely to be defaulted, should be an attributed.
If the only value was going to be a single literal, it should be an attribute.
If the value of something needs to be further expanded, it should be represnted
Generally, an implied default of the most common value in the immediate future should be provided to shorten signatures. Note that providing such a default does not lengthen any case where the value is explicitly provided.