OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] anonymous types


At 05:24 PM 10/7/2003 +0200, Juan Carlos Cruellas Ibarz wrote:

>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>
>[...]
>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
>[...]
>I would say that this approach is first shorter, and second more
>aligned with reusability of types...

That's what I thought you were saying.  I see your point.  Personally, I 
just like the greater readability of the 1st approach.



>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...

It's only redundant if we end up re-using our elements, or someone else does.

In that case, it would make sense to consider named types.  But none of the 
elements within the current schema look re-usable, so could we not bother 
giving them named types?


>  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...

I agreee - if we do anticipate a type being re-used, it's easy enough to 
define it as a named type.

Trevor 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]