Re: Opaque (Client) Data

Hi Stephen -

>(unless you want to suggest clearer text that'd help the next developer not 
>miss this)

It may be somewhat clearer (and consistent with the rest of the spec) if 
'Section
3.1.4 Element <OpaqueClientData>' also mentioned its child element 
<OpaqueData> stating that
there is a 1-many relationship between the two.

Something like:

  [94]The <OpaqueClientData> element contains data specified by the client 
that is opaque
  to the service. <OpaqueClientData> has the following element

    <OpaqueData> [1..AnyNumber]
      Data specified by the client that is opaque to the service.

  An XKMS service SHOULD return the <OpaqueClientData> element specified in 
a request, including
  its children, unmodified in the corresponding response.

The following adjustment to '3.1.1 Type MessageAbstractType' may also be 
useful:

    <OpaqueClientData> [Optional]
      A collection of data specified by the client that is opaque to the 
service.
      An XKMS service SHOULD return the content of the <OpaqueClientData> 
element unmodified
      in a response with status code Success.

Regards
Tommy

>From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>To: tommy lindberg <lindberg_tommy@hotmail.com>
>CC: alvarorg@cs.tcd.ie, www-xkms@w3.org
>Subject: Re: Opaque (Client) Data
>Date: Wed, 01 Sep 2004 12:51:54 +0100
>
>
>
>Hi Tommy,
>
>Fine by me.
>
>So assuming no objections when those on the wrong^h^h^h^h^hother side
>of the Atlantic and elsewhere wake up, there's nothing to do and no
>need to open an issue (unless you want to suggest clearer text that'd
>help the next developer not miss this).
>
>Cheers,
>Stephen.
>
>tommy lindberg wrote:
>
>>
>>I'd favor leaving the schema as is in this respect.  I have fixed my code 
>>to handle the multiplicity correctly; not yet deployed.
>>
>>Regards,
>>Tommy
>>
>>>From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>>To: Guillermo Álvaro Rey <alvarorg@cs.tcd.ie>
>>>CC: www-xkms@w3.org
>>>Subject: Re: Opaque (Client) Data
>>>Date: Wed, 01 Sep 2004 12:06:19 +0100
>>>
>>>
>>>
>>>I could live with either interpretation, but slightly prefer
>>>to allow >1 because:
>>>
>>>- its the current schema
>>>- I think it might be easier for a client who's using field
>>>   to be able to easily add/find values (though this is a bit
>>>   tenuous, I admit)
>>>
>>>But I'm happy to change the schema if coders prefer to only
>>>allow one OpaqueData to be present.
>>>
>>>I doubt that anyone's got a real use for >1 OpaqueData so far,
>>>so this ought to be a safe enough change to make if you guys
>>>want to do it (please yell if this is untrue).
>>>
>>>Cheers,
>>>Stephen.
>>>
>>>Guillermo Álvaro Rey wrote:
>>>
>>>>Hi all,
>>>>
>>>>Following our client-server tests Tommy and myself were discussing about
>>>>the number of OpaqueData elements that the specification *intend* to
>>>>allow in an OpaqueClientData element.
>>>>
>>>>It seems that the way the schema currently stands multiple OpaqueData
>>>>children are allowed for a OpaqueClientData element,
>>>>
>>>>         <sequence maxOccurs="unbounded">
>>>>            <element ref="xkms:OpaqueData" minOccurs="0"/>
>>>>         </sequence>
>>>>
>>>>, but currently only the first one is handled by Tommy's implementation
>>>>and so we would like to get confirmation that that's not the expected
>>>>behaviour.
>>>>
>>>>Cheers,
>>>>
>>>>  - -Guillermo
>>>>
>>>>
>>>>
>>>
>>
>>_________________________________________________________________
>>Tired of spam? Get advanced junk mail protection with MSN 8. 
>>http://join.msn.com/?page=features/junkmail
>>
>

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Received on Wednesday, 1 September 2004 16:38:43 UTC