Subject: XML InfoSet and property value preservation

From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Nov 2005 12:44:16 -0800

Lately we've been talking about what parts of a property value the 
server must preserve, and what parts it can lose. Some examples:
  - Whitespace in values (TEXT or Mixed) must be preserved, we all 
agreed on this
  - Whitespace within element tags might be insignificant, e.g. extra 
spaces between attribute declarations
  - Exact prefixes used to declare namespaces (can the server replace 
the "C:" prefix for a namespace with "ns-1" or other when it 
reconstructs the value)
  - Attributes and values on the property element itself...

Rather than attack these questions piecemeal, Julian suggested a more 
principled approach of using XML InfoSet.  So I went off to read the 
spec:
http://www.w3.org/TR/xml-infoset/

While it would indeed be great to refer to another standard, I wanted 
to raise a few issues.

1.  It's hard to read.  There are no examples. While some things are 
clear -- e.g. for an element, it states that the namespace name and 
local name of the element are part of the InfoSet -- I don't find that 
the "negative space" is clearly defined.  As a client implementor, it's 
hard for me to read this and determine what the server might legally 
change in the property value I might provide.

2.  InfoSet requires the prefixes of namespaces to be preserved.  Some 
WebDAV servers today do not do this so this would make them 
non-compliant.  Similarly, if I'm reading it correctly, it requires 
that namespace declarations be preserved as part of the element where 
the client declared them -- another requirement that existing servers 
don't meet.

3.  It doesn't deal with the boundary that WebDAV defines between 
property name and property value.  We still ought to specify that stuff 
ourselves.  For example, are attributes on the property name element 
considered part of the property value.

Has anybody besides Julian and myself read this spec?  Does anybody 
have thoughts on whether this approach is still advisable?

thanks,
Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Nov 2005 22:00:49 +0100

Lisa Dusseault wrote:
> ...
> non-compliant.  Similarly, if I'm reading it correctly, it requires that 
> namespace declarations be preserved as part of the element where the 
> client declared them -- another requirement that existing servers don't 
> meet.
 > ...

You're confusing the terminology (that we can re-use) with the question 
what parts of the Infoset WebDAV wants to make reound-trippable. Those 
do not need to be the same. The XML Infoset spec just helps in talking 
about these things.

> considered part of the property value.

Yes, we need to define that.

> Has anybody besides Julian and myself read this spec?  Does anybody have 
> thoughts on whether this approach is still advisable?

Alternate approaches would be to use DOM or XPath terminology.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 3 Nov 2005 14:45:17 -0800

On Nov 3, 2005, at 1:00 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> ...
>> 2.  InfoSet requires the prefixes of namespaces to be preserved.  
>> Some WebDAV servers today do not do this so this would make them 
> You're confusing the terminology (that we can re-use) with the 
> question what parts of the Infoset WebDAV wants to make 
> reound-trippable. Those do not need to be the same. The XML Infoset 
> spec just helps in talking about these things.

Fair enough, I think the terminology does make things clear and we can 
define our own list about what's round-tripped.   On those terms I'm 
perfectly in favour of using InfoSet terminology. So does this boil 
down to saying something like:

   "All Information Items as defined in XML InfoSet [ref] MUST be 
round-tripped as part of the property value, with the exception of the 
following
    - On an element information item: the prefix and namespace attributes
    - On an attribute information item: the prefix
    - On a namespace information item: the prefix

   Anything that is not part of the Information Set does not need to be 
preserved by the server."

>> property name and property value.  We still ought to specify that 
>> stuff ourselves.  For example, are attributes on the property name 
>> element considered part of the property value.
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Nov 2005 21:04:10 +0100

Lisa Dusseault wrote:
> perfectly in favour of using InfoSet terminology. So does this boil down 
> to saying something like:
> 

Why would we need any Namespace Information Items anyway? I thought 
namespace declarations weren't considered important, as long as 
namespace names are preserved for each item?

> preserved by the server."

So are comments, processing instructions, unparsed entities and so on 
in? Probably not.

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:

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.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 11 Nov 2005 14:53:57 -0800

In WebDAV implementations today, the only InfoSet piece that we know 
isn't always preserved on properties is the namespace prefix (and thus 
the namespace declaration attributes might also be rewritten).   I'd 
assume we want to encourage new implementations to have at least as 
much preservation/fidelity as existing implementations, and to make 
implementations tend to be consistent with each other.  So why would we 
allow servers to strip out stuff like comments?  If servers reliably 
preserve those today, I don't see why we'd explicitly allow those to 
stop being preserved.

Is there some reason why we would choose to be lax on this in the 
specification?

Lisa

On Nov 6, 2005, at 12:04 PM, Julian Reschke wrote:

>> Fair enough, I think the terminology does make things clear and we 
>> can define our own list about what's round-tripped.   On those terms 
>> I'm perfectly in favour of using InfoSet terminology. So does this 
>> boil down to saying something like:
>> round-tripped as part of the property value, with the exception of 
>> the following
>>   Anything that is not part of the Information Set does not need to 
>> be preserved by the server."
>> ...
>
> 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:
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2005 09:01:53 +0100

> the namespace declaration attributes might also be rewritten).   I'd 

I'm not sure how you can say that. I just tried with comments and PIs in 
Apache/moddav, and they aren't preserved. Do you have any data 
supporting your claim?

> assume we want to encourage new implementations to have at least as much 
> preservation/fidelity as existing implementations, and to make 

Well, because commments are just that -- comments?

> preserve those today, I don't see why we'd explicitly allow those to 

This I agree with, but it seems that we don't have the necessary 
supporting data.

> Is there some reason why we would choose to be lax on this in the 

I don't want to be lax. We should either document what we have today (if 
we want to advance RFC2518), or document what we tjink would be good 
(staying at proposed). Throwing in things like PIs, but keeping out 
*essential* things like prefixes doesn't make any sense to me, though.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Nov 2005 10:02:38 -0800

On Nov 15, 2005, at 12:01 AM, Julian Reschke wrote:

>> isn't always preserved on properties is the namespace prefix (and 
>> thus the namespace declaration attributes might also be rewritten).   
>> I'd
>
> I'm not sure how you can say that. I just tried with comments and PIs 
> in Apache/moddav, and they aren't preserved. Do you have any data 
> supporting your claim?

No -- I only said we don't *know* of other InfoSet items being lost, 
and now you've provided fresh data for this list.  If it's been said 
before, I'd either missed it or forgotten.

>
> I don't want to be lax. We should either document what we have today 
> (if we want to advance RFC2518), or document what we tjink would be 
> good (staying at proposed). Throwing in things like PIs, but keeping 
> out *essential* things like prefixes doesn't make any sense to me, 
> though.

Great; so what's a principled basis on which to make this decision?  I 
can see one extreme option, plus an "exclusionary" choice and an 
"inclusionary" choice based on what we know implementations do today.  
This isn't full text for each point but just illustrative:

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.]
Exclusionary option: All InfoSet items MUST be preserved, except for 
the ones we know aren't preserved in some server implementations 
(comments and prefixes... )  [This encourages nearly as great 
consistency as the extreme option.]
Inclusionary option: Of the InfoSet items, only the ones we know client 
implementations really need (text, element, attribute name and 
value...) MUST be preserved.  [The difference between this one and 
exclusionary option covers InfoSet items like Processing Instructions.  
]

Has anybody considered this issue besides myself and Julian?  Does 
anybody with an implementation wish to speak up and argue why it might 
be important to preserve or useful to discard various pieces of the 
InfoSet in property values?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Nov 2005 20:02:21 +0100

> This isn't full text for each point but just illustrative:

I'm tempted to say "common sense". That PIs and comments do not 
necessarily round-trip should be quite clear.

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

Looking at what exactly is in (see 
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem>), I find 
that completely unreasonable.

> Exclusionary option: All InfoSet items MUST be preserved, except for the 
> ones we know aren't preserved in some server implementations (comments 
> and prefixes... )  [This encourages nearly as great consistency as the 
> extreme option.]
> implementations really need (text, element, attribute name and value...) 
> MUST be preserved.  [The difference between this one and exclusionary 
> option covers InfoSet items like Processing Instructions.  ]

I think the latter option has the advantage that it's shorter to write 
down, and easier to understand.

Best regards, Julian