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

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

>> >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.
>
I am completely sure that there are other parts of the document that 
will demand from readers much more attention than the sentence:

"When the server sends back a SignResponse, the Result element will only
contain the ServerProcessingResult. When the server generates a
VerifyResponse,
the Result element will contain both ServerProcessingResult and Status
elements."

Which is pretty explanatory, does not bring any big problems to
implementors and
leaves the schema quite clean...
And we will have quite a lot of elements in the protocol that under certain
circumpstances
have certain parts and under other they will have different parts: think of
Options element
itself.... 


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

I would say that the criteria for definining an element is not whether it
contains
two or more elements, but if it makes sense to group these two elements even
if sometimes one of them does not appear

>
>Yeah, but that adds even more "stuff" to the schema.  It's "excess stuff" 
>that I don't like.  Perhaps excessively.  
>
I would not say that to define a type where to
group what the server has to report back to the client, which actually means
to define a type of two elements is "excess stuff"?


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

I thought that I was following the criteria that have lead the definition
of the
requests: input documents and options; here in the responses: 
results reports and additional outputs.

Well, afte all this writing I think that one proposal is:

>> ><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="dss:Status"/>
>> >             <xs:element ref="dss:Outputs" minOccurs="0"/>
>> >         </xs:sequence>
>> >     </xs:complexType>
>> ></xs:element>


And the other is:

>> ><xs:element name="SignResponse">
>> >     <xs:complexType>
>> >         <xs:sequence>
>> >             <xs:element ref="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="Result">
>> >             <xs:element ref="dss:Outputs" minOccurs="0"/>
>> >         </xs:sequence>
>> >     </xs:complexType>
>> ></xs:element>

>> ><xs:element name="Result">
>> >     <xs:complexType>
>> >         <xs:sequence>
>> >             <xs:element ref="ServerProcessingResult">
>> >             <xs:element ref="dss:Status" minOccurs="0"/>
>> >         </xs:sequence>
>> >     </xs:complexType>
>> ></xs:element>



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

Yes, now it is a matter of personal taste, so let us speak the rest....
what I think
is crucial is to have separated both kinds of reports, those on whether the
server 
has completed the process and those on the validity or not of the
signature.....

>

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

I think that I have written the one you meant above.... It is19:50 here, I
leave the office now,....


Juan Carlos
>
>Trevor 
>