Re: Opaque (Client) Data

I have updated the spec on my side to make these changes:

   Issue TBD: Fixed Para 86 - inserted "A collection of d" in the OpaqueClientData [Optional] section
   Issue TBD: Fixed Para 94: inserted ", including its children," to clarify further

I felt that the fix to para 94 was not necessary, but, as it is confusing to a few folks, it does not hurt to add the phrase.  

One other item that I am thinking of adding to the specification is:

"For elements that have maxOccurs="unbounded", implementations can define WSDLs for that kind of a service which restrict the maxOccurs value to a finite value."

By doing this, we can keep the schema intact and the implementations can scale.

 

/Shivaram
tommy lindberg <lindberg_tommy@hotmail.com> wrote:


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 ' also mentioned its child element 
stating that
there is a 1-many relationship between the two.

Something like:

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

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

An XKMS service SHOULD return the 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:

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

Regards
Tommy

>From: Stephen Farrell 
>To: tommy lindberg 

>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 
>>>To: Guillermo Álvaro Rey 
>>>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,
>>>>
>>>> 
>>>> 
>>>> 
>>>>
>>>>, 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




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Received on Thursday, 2 September 2004 03:13:37 UTC