- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Wed, 01 Sep 2004 12:51:54 +0100
- To: tommy lindberg <lindberg_tommy@hotmail.com>
- Cc: alvarorg@cs.tcd.ie, www-xkms@w3.org
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 >
Received on Wednesday, 1 September 2004 11:50:45 UTC