- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 18 Nov 2005 16:21:18 +0100
- To: Cullen Jennings <fluffy@cisco.com>
- CC: WebDav <w3c-dist-auth@w3.org>
Cullen Jennings wrote: > On 11/6/05 12:04 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > >> So are comments, processing instructions, unparsed entities and so on >> in? Probably not. > Assume you mean MUST NOT and is there any more to the "so on" No. MUST NOT would mean that servers aren't allowed to persist these. A server should be free to persist more than then required set of items, though. >> Looking at the large set of information items, it's probably simpler if >> we just list the items we want to be round-tripped, such as: > So assuming you mean "server MUST preserver" >> 1) On the property element itself: [namespace name], [local name], >> [children] of type element or character, plus [attributes] named >> "xml:lang" present on the element itself or it's closest ancestor >> >> 2) On all children of the property element: [namespace name], [local >> name], [attributes] and [children] of type element or character. >> >> Regarding the issue that started the whole discussion: we IMHO should >> encourage servers to preserve the [prefix} on all but the property >> element itself, and warn clients about information loss for those >> servers that don't. > I'm a bit lost on the point of encouraging them to preserver this. Do we > plan to make a later version of the specification require this? If not, I'm > not sure I see the point. (I do see the point of telling clients they can't > count on it) I would hope that recommending it would encourage server implementors to implement it, so it could be made a required feature later. > If others understand this proposal, I've got not complaint with it and > please ignore this email but when I read it I did not realize this was a > specific proposal and saw it more as a general leaning towards what a > proposal might look like. I was happy to see the outline post but it seemed > like you had an excellent grasp on what the problem was here and might be > able to provide some crisp description of the solution and a bit of > explanation on why this was the right solution so that none of us were > doomed to an endless recurring conversation. Seriously, you are in a great > position to put the nail in the coffin on this one once and for all. Make it > end. I agree this is not "camera-ready" spec text. If we agree on the high-level approach, I can try to write it down in a manner that works in the spec. Best regards, Julian
Received on Friday, 18 November 2005 15:22:33 UTC