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


Good suggestion, Anil; I'll try it next week (another deadline
this week) and get back to the TC.

Arshad

Anil Saldhana wrote:
> 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]