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] Core protocol: is the <Status> element the status of what has been validated ?


>
>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.... 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....
And going into the details, what is the difference between
<ServerProcessingResult>
and <Result> in your <VerifyResponse>? and why <Status> should be optional?
I think
that in THIS particular schema it should be mandatory...
But anyway, I still prefer the proposal I made.

Juan Carlos.

>What do other people think?
>
>Trevor
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>


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