Subject: Fwd: XML InfoSet and property value preservation

From: Jim Whitehead <[email-masked]>
Date: Wed, 16 Nov 2005 09:33:39 -0800

Begin forwarded message:

> From: "Lukas Mathis" <[email-masked]>
> Date: November 15, 2005 11:53:39 PM PST
> To: <[email-masked]>
> Subject: RE: XML InfoSet and property value preservation
>
>> Extreme option:  All InfoSet items MUST be preserved.  [This clearly
>> has the disadvantage of making existing implementations change their
>> code to comply, but has the advantage of simplicity and enforcing the
>> greatest consistency between servers.]
>
> Maybe I'm missing something, so I hope somebody can explain this to  
> me:
> Are you arguing about whether a server should preserve data which  
> has no
> specific semantic meaning (comments) or which could be changed to a
> semantic equivalent in XML (namespace prefixes)?
>
> Maybe I don't understand the issue well enough to comment on it,  
> but I'd
> tend to go with the last option - only require servers to preserve  
> that
> which is really needed by clients.
>
> Lukas
>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Nov 2005 19:42:23 +0100

Jim Whitehead wrote:
> 
> 
> Begin forwarded message:
> 
>> *From: *"Lukas Mathis" <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date: *November 15, 2005 11:53:39 PM PST
>> *To: *<[email-masked] <mailto:[email-masked]>>
>> *Subject: **RE: XML InfoSet and property value preservation*
>>
>> Maybe I'm missing something, so I hope somebody can explain this to me:
>> Are you arguing about whether a server should preserve data which has no
>> Maybe I don't understand the issue well enough to comment on it, but I'd
>> tend to go with the last option - only require servers to preserve that

Yes, sure. The trouble actually is to figure out what this is.

For instance, I do agree with you that comments do not need to be 
preserved, but I don't agree that namespace prefixes are irrelevant.

And of course there's the separate issue that we can't simply invent new 
  requirements without also thinking about how to get servers to quickly 
support these....

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Nov 2005 12:39:25 -0800

Can you put out a proposal of which of the items you think clients should be
able to depend on the clients preserving?

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 16 Nov 2005 14:55:54 -0800

Hate to sound ignorant again, but, well I guess I don't hate it
that much...

    Recognizing that we can't say that XML sub-elements aren't allowed
in property elements because of history, the spec should encourage
clients that want to know that their data will be preserved exactly
as-is (comments and all) SHOULD encode their content, and perhaps the
spec should recommend an encoding (eg. escaped XML/CDATA) for
property contents.  This has the advantage of working reliably on
100% of existing servers, regardless of how they expand namespaces,
ignore comments (or not), use CDATA or escaped XML, etc.

    Clients putting sub-elements into properties should accept that
the server will likely parse those elements, potentially storing that
into some normative form, then re-render that into XML when asked for
it later, and that semantically equivalent but byte-for-byte
different data may come back.  I think forcing a server author to
care about preserving the original XML rendering at all is a bad idea.

    WebDAV is already pretty complicated.  XML with namespaces is no
small part of that complexity. Why make it harder when an easy
solution is already available in current implementations?

	-wsv

On Nov 16, 2005, at 10:42 AM, Julian Reschke wrote:

> And of course there's the separate issue that we can't simply  
> invent new  requirements without also thinking about how to get  
> servers to quickly support these....
>
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Nov 2005 11:22:53 +0100

> in property elements because of history, the spec should encourage

XML sub-elements *are* allowed in property values. RFC2518 says this, 
and many servers get this right.

> ignore comments (or not), use CDATA or escaped XML, etc.

If a client really expects the property value to be treated as text, 
yes, it should send it as text.

The issue here that there are very good reasons to use XML, for 
instance, when the format of the property is already defined as XML 
(such as when tunneling DC metadata in WebDAV properties).

> care about preserving the original XML rendering at all is a bad idea.

As far as I can tell, nobody asked for that.

> solution is already available in current implementations?

We don't want to make it harder. On the other hand, we also don't want 
to remove something I feel is an important feature, just because some 
servers do not get it right (usually, these are the same servers that 
don't get other things right as well, so trying to please those usually 
would mean taking out lots of other things).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Nov 2005 11:41:06 +0100

> able to depend on the clients preserving?

That's in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0467.html>.

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 17 Nov 2005 10:02:19 -0800

Typo; I meant are, not aren't.  You're right, of course.

	-wsv

On Nov 17, 2005, at 2:22 AM, Julian Reschke wrote:

> XML sub-elements *are* allowed in property values. RFC2518 says  
> this, and many servers get this right.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 17 Nov 2005 20:35:30 -0800

> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0467.html>.

Ok so to trying to make sure I understand your proposal ...

On 11/6/05 12:04 PM, "Julian Reschke" <[email-masked]> 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"
> 
> 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) 
> Best regards, Julian

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. 

Cullen

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Nov 2005 16:21:18 +0100

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

> not sure I see the point. (I do see the point of telling clients they can't

I would hope that recommending it would encourage server implementors to 
implement it, so it could be made a required feature later.

> position to put the nail in the coffin on this one once and for all. Make it

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