Trevor
See below:
At 13:33 06/10/2003 -0700, Trevor Perrin wrote:
>
>Juan Carlos pointed out 2 things about the schema -
>
> 1) The <KeySelector> includes a <ds:Signature>, instead of being of type
>ds:SignatureType.
Well, in fact this not what I tried to say. Sorry for the missunderstanding.
What I tried to say is that currently we have the following definition for
the KeySelector element:
<xs:element name="KeySelector">
<xs:complexType>
<xs:sequence>
<xs:element ref="ds:KeyInfo"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Doing that our KeySelector would be something like:
<KeySelector>
<ds:KeyInfo>
<!-- here the KeyInfo contents as defined in XMLDSIG -->
</KeyInfo>
</KeySelector>
My point was that if we changed the element definition to:
<xs:element name="KeySelector" type="ds:KeyInfoType"/>
our element would be:
<KeySelector>
<!-- here the KeyInfo contents as defined in XMLDSIG
BUT WITHOUT THE EXTRA ENVELOPING TAGS
<ds:KeyInfo> -->
</KeySelector>
I would say that this approach is first shorter, and second more
aligned with reusability of types...
Which means that we have an extra level of tags ...
> 2) Elements are defined with "Anonymous Type Definitions" [1].
>
>As for (1), it seems more readable to re-use element names, so you can look
>at an XML document and recognize "that's a ds:Transforms", "that's a
>ds:KeyInfo", etc., without consulting the schema to figure out what type
>everything is.
>
Well, I would say that this way of building structured information is very
redundant in the end, and this with a language as XML that it is very
verbose by itself... In addition, generally speaking, if I want to completelly
understand a XML document in depth, I have to read the corresponding
schema, so that I can see not only what is in the XML document but
also what is NOT in the document but could be (optional elements), etc...
My point is that a deep understanding of a document demnads the
knowledge of the schema.
>As for (2), if we did it the Juan Carlos / XML-DSIG way, where every
>element has a named Type, then other schemas could re-use our types without
>re-using our names. But none of the protocol pieces seem reusable anyways,
>so named types don't seem to have much benefit.
I have read the message by Tim and I agree with him... sometimes in the
same schema that one is defining there is a need for a named type reusage...
so I would say that at least with those items that could be reused outside
the protocol we should allow named types...
Juan Carlos
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>
