W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: XML InfoSet and property value preservation

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 18 Nov 2005 16:21:18 +0100
Message-ID: <437DF16E.3090807@gmx.de>
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"


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, 

>> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC