OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

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


Subject: Re: [ekmi] Request ID or entire request in sksml response


Arshad,
  thanks for the clarification. 

I think the schema looks good. 

As a suggestion to further validate the schema, you can try xjc in the 
sun jaxb2 implementation to see if the conversion
into Java classes produces any visible schema issues.

Regards,
Anil

Arshad Noor wrote:
> That is correct, Anil; they are all valid.  And, the reason is:
> a <SymkeyRequest> could have requested multiple symmetric keys
> from the SKS server - some new and perhaps, some existing.
>
> As a result, the response can contain all the elements you show
> in your examples; some could be valid <Symkey> elements with new
> or existing keys; some could be <SymkeyWorkInProgress> (even if
> the request was made synchronously, we have to allow for the
> possibility that the SKS server cannot return a <Symkey>, but at
> the same time, it did not run into any errors to return a
> <SymkeyError>) and finally, some could result in <SymeyError>s.
>
> Since we can't predict how many key-requests might be within
> a single <SymkeyRequest>, we have to accommodate for all types
> of elements in the <SymkeyResponse>.
>
> Does that clear up the confusion?
>
> Arshad
>
> Anil Saldhana wrote:
>> Hi Arshad,
>>  I have a doubt.
>>
>> ===========================================================
>> <xsd:element name="SymkeyResponse">
>>        <xsd:complexType>
>>            <xsd:choice>
>>                <xsd:sequence>
>>                    <xsd:element ref="ekmi:Symkey" minOccurs="1" 
>> maxOccurs="unbounded"/>
>>                    <xsd:element ref="ekmi:SymkeyError" minOccurs="0" 
>> maxOccurs="unbounded"/>                      <xsd:element 
>> ref="ekmi:SymkeyWorkInProgress" minOccurs="0" maxOccurs="unbounded"/>
>>                </xsd:sequence>
>>                <xsd:sequence>
>>                    <xsd:element ref="ekmi:SymkeyError" minOccurs="1" 
>> maxOccurs="unbounded"/>
>>                    <xsd:element ref="ekmi:SymkeyWorkInProgress" 
>> minOccurs="0" maxOccurs="unbounded"/>
>>                </xsd:sequence>
>>                <xsd:sequence>
>>                    <xsd:element ref="ekmi:SymkeyWorkInProgress" 
>> minOccurs="1" maxOccurs="unbounded"/>                  </xsd:sequence>
>>            </xsd:choice>
>>        </xsd:complexType>
>>    </xsd:element>
>> ===========================================================
>>
>> What this is saying is that:
>> <ekmi:SymkeyResponse>
>>   <ekmi:SymKey/>
>>   <ekmi:SymKeyWorkInProgress/>
>> </ekmi:SymkeyResponse>
>>
>> or
>>
>> <ekmi:SymkeyResponse>
>>   <ekmi:SymKeyError/>
>>   <ekmi:SymKeyWorkInProgress/>
>> </ekmi:SymkeyResponse>
>>
>> or
>>
>> <ekmi:SymkeyResponse>
>>   <ekmi:SymKey/>
>>   <ekmi:SymKeyError/>
>> </ekmi:SymkeyResponse>
>>
>> are all valid constructs.
>>
>> Regards,
>> Anil



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