At 07:17 PM 9/24/2003 -0400, Rich Salz wrote:
> > - you have <xs:choice minOccurs="0" maxOccurs="unbounded"> instead of
> > just <xs:choice>. Could every dss:Parameter just have a single content
> > element?
>
>You're right, that's a cut and paste error (from Parameters); it should
>just be <xs:choice>
>
> > - why <xs:complexType mixed="true"> instead of just <xs:complexType>?
> > - do we need <xs:attribute name="type" type="xs:anyURI"
> > use="required"/>? Could the server just look at the name of its single
> > content element?
>
>Some parameters might just have content. For example
> <dss:Parameter type="http://www.verisign.com/cps/foo">
> here is the text of our certification practice
> statement.
> </dss:Parameter>
>
>I'm not opposed to forcing that to be rewritten such that the interior
>element defines the content:
> <dss:Parameter>
> <vrsn:cps xmlns:vrsn="http://www.verisign.com/cps/foo">
> here is the text of our certification practice
> statement.
> </vrsn:cps>
> </dss:Parameter>
If we rewrote it that way, the only function of dss:Parameter would be to
contain the "mustUnderstand" attribute. At the f2f we decided that the
server should *have* to understand any client parameters, or reject the
entire request. Just made things simpler. We could revisit that. But if
we got rid of mustUnderstand we wouldn't need dss:Parameter, we could just do:
<xs:element name="Parameters">
<xs:complexType>
<xs:sequence>
<xs:any processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
And then you just add parameters directly under this. Maybe that's a
little simpler, I dunno if it sacrifices anything important.
Trevor
