Re: [dss] Core protocol: is the <Status> element the status of what has been validated ?

[Trevor Perrin <trevp@trevp.net>]

At 05:13 PM 10/23/2003 +0200, Juan Carlos Cruellas Ibarz wrote:

> >
> >Yes.  I'm sure there's other cases we need to cover too.
> >
> >
>OK..... we will find them out....
> >
> >
> >>I propose you the following:
> >>
> >><xs:element name="SignResponse">
> >>          <xs:complexType>
> >>                  <xs:sequence>
> >>                          <xs:element ref="dss:Result"/>
> >>                          <xs:element ref="dss:Signature" minOccurs="0"/>
> >>                          <xs:element ref="dss:Outputs" minOccurs="0"/>
> >>                  </xs:sequence>
> >>          </xs:complexType>
> >></xs:element>
> >>
> >><xs:element name="VerifyResponse">
> >>          <xs:complexType>
> >>                  <xs:sequence>
> >>                          <xs:element ref="dss:Result"/>
> >>                          <xs:element ref="dss:Outputs" minOccurs="0"/>
> >>                  </xs:sequence>
> >>          </xs:complexType>
> >></xs:element>
> >>
> >>
> >>And then define a Result having two different elements:
> >><xs:element name="Result" type="ResultType"/>
> >><xs:complexType name="ResultType">
> >>         <xs:sequence>
> >>                 <xs:element ref="ServerProcessingResult">
> >>                 <xs:element ref="Status" minOccurs="0">
> >>         <xs:sequence/>
> >></xs:complexType>
> >>
> >>---> I am using named types just because I remember better the
> >>syntax...
>
> >
> >Would your <Status> element ever be used within a <SignResponse>?  It seems
> >like it wouldn't.
>
>I guess not: the only thing that a SignResponse would generate is the
>signature itself
>and the report saying: I have successfully completed.
>
>
>
> >So I'd rather get rid of the <Result>, and just include
> >its children directly:
>Why?, what I am proposing is to re-use <Result> in both places. The
>only difference is that in the SignatureResponse it has only one child
>and in the ValidationResponse it has two children

Since <Result> has a child element that isn't relevant to <SignResponse>, I 
wouldn't use it within <SignResponse>, otherwise <SignResponse> has 
something unneeded hanging off it.  Yeah, it's optional, but it would still 
be in the schema, which seems a bit messy.

You could use <Result> within <VerifyResponse>, but I don't see the point 
in having a wrapper element just to contain 1 or 2 children.


>.... The first level
>is clean and symmetric, we are re-using <Result> and within it
>we clearly sepparate what is status result and what is the processing result.
>We keep them related, as you mention, by keeping them as children of a
>general element that contains, grouped but not mixed all the information
>concerning
>the results...
>
> >
> ><xs:element name="SignResponse">
> >     <xs:complexType>
> >         <xs:sequence>
> >             <xs:element ref="ServerProcessingResult">
> >             <xs:element ref="dss:Signature" minOccurs="0"/>
> >             <xs:element ref="dss:Outputs" minOccurs="0"/>
> >         </xs:sequence>
> >     </xs:complexType>
> ></xs:element>
> >
> ><xs:element name="VerifyResponse">
> >     <xs:complexType>
> >         <xs:sequence>
> >             <xs:element ref="ServerProcessingResult">
> >             <xs:element ref="Status"
> >minOccurs="0">
> >             <xs:element ref="dss:Result"/>
> >             <xs:element ref="dss:Outputs" minOccurs="0"/>
> >         </xs:sequence>
> >     </xs:complexType>
> ></xs:element>
> >
> >
> >Still, I find this less... aesthetically pleasing then just re-using a
> >single <Status> element for both.  I doubt we're going to convince each
> >other, so I think we should try to get some other opinions as a tie-breaker.
>
>
>Yes, sure, it is less aesthetically pleasing, that is why, after having the
>status
>and the server processing in different elements, I grouped them in one
>element, as they are, as you say, related....

Yeah, but that adds even more "stuff" to the schema.  It's "excess stuff" 
that I don't like.  Perhaps excessively.  Why add another element just to 
contain one or two children?  Why add another "status-like" element when we 
can re-use the <Status> we've already got?

But your arguments are reasonable.  If some-one else expresses an opinion 
one way or the other, I think we should go with that.


>And going into the details, what is the difference between
><ServerProcessingResult>
>and <Result> in your <VerifyResponse>?

bad copy-and-paste, ignore the <Result>

>  and why <Status> should be optional?
>I think
>that in THIS particular schema it should be mandatory...

sorry, a typo again.  All I meant to do was replace <Result> with 
<ServerProcessingResult> and <Status>..


Trevor