[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] full schema for signing request
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]