Re: DataModel Types and Values in Solo's Draft

At 13:30 99/09/23 -0400, dee3@us.ibm.com wrote:
 >@@@ Since signaturevalue is opaque, it has no internal structure visible.
So it
 >doesn't have to be content, one of whose advantages is that it can be
composite.
 >It's also the case that ' value=""' is shorter thant '><signaturevalue'.
These
 >may not make any sense as reasons from a data model view but they are
probably
 >how some people in the WG are thinking.  I agree that <dsig:sigval
 >encoding="base64">8uj38idk</dsig:sigval> where encoding defaulted to base64
 >would be more logical.

Ok. I didn't make that change, but once we do the big syntax jiggle, I think
we'll want to be consistent with the way we use attributes and element
content.

 >  <dsig:keyinfo>
 >     <dsig:keyattributes>
 >       <dsig:keyname>3</dsig:keyname>
 >       <dsig:keyvalue>4</dsig:keyvalue>
 >       <dsig:keyretrievalmethod>urn:DH</dsig:keyretrievalmethod>
 >     </dsig:keyattributes>
 >  </dsig:keyinfo>
 >keyinfo is a property that relates signature to keyattributes.
keyattributes
 >has numerous properties (keyname, keyvalue) all with different values.
 >
 >@@@ I'm not sure you need the "keyattributes" level but otherwise I tend to
 >agree with you.

This is the trick with using "striped XML syntax" to represent the data
structure. keyattributes is there such that one can say "keyinfo is a
property that relates signature to keyattributes." For instance the DLG
would look like where '('$resource')' and '"'literal'"':

(signature) --keinfo--> (keyattributes)
        (keyattributes) --keyname--> "3"
        (keyattributes) --keyvalue--> "4"

Or translated into tuple syntax

{signature, keyinfo, keyattributes}
{keyattributes, keyname, "3"}
{keyattributes, kevalue, "4"}

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

Received on Thursday, 23 September 1999 18:26:28 UTC