- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 23 Sep 2004 16:06:59 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>, webdav <w3c-dist-auth@w3.org>
Lisa Dusseault wrote: > Can we include an example of an array of XML elements in the draft, so > that implementors are likely to do it the same way? I'd prefer not to. Adding examples for more then the absolute trivial things (like booleans or dates) is likely to open the proverbial can of worms, because people have different tastes about types and optimal serializations. So in doubt I'd even prefer to *remove* the current appendix (as I'm not convinced that this is a good serialization format given it's based on an outdated SOAP spec; it just happens to be what we *do* implement right now). > I would also like to request some words on ordering in the draft, > although I agree that the W3C Note says that ordering is significant > that doesn't say everything. > - Say that "servers MUST preserve ordering if the server is storing a > dead property in array format" or something equivalent Again, I'd prefer not to. An array is an array; not a set. > - What clients should do is a little less clear but let's take a stab > at it: clients that are adding a new value, removing a value, or > changing a value in an array SHOULD maintain the rest of the array > ordering, unless the user actually intends to resort the array to a > different order. Well, that's the whole point of having an array. I understand that you are particulary interested in this data type because you'll need it. It seems to me that the best strategy for you is to define that type in a separate document (possibly standalone or caldav), and let the property types spec stay out of this business. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 23 September 2004 14:07:33 UTC