Subject: Plan to resolve issues in 2518bis

From: Cullen Jennings <[email-masked]>
Date: Tue, 04 Oct 2005 10:31:08 -0700

I had a phone call with Elias, Julian, Geoffrey, Lisa, and Jim today to see
what we could all do to get things moving on 2518bis.

Elias kindly volunteered to collect all the know issues and put them in
bugzilla. He is going to tell us how he will mark in bugzilla two different
states. One state is when the WG agrees on general way to resolved the issue
but has not updated drafts yet or figured out exact text, and other state is
when the actual text has been put into the draft.

If people can send text to the list proposing the text they want put into
2518bis-07 to fix a given issue that would be great.

We are then going to have some conference calls to run through all the
issues - we know some will be easy and some will be hard. Initially we are
going to try and knock of the easy one quickly and figure out which ones are
hard and start an email thread on the list for the hard ones. If we come up
with a proposed text on the call, it will still be approved on the list. The
calls will help set a regular event to move the draft forward and will also
help us quickly figure out where we all agree and disagree. Hard issues that
need discussion will still be discussed on the list.

Julian is going to start a thread on one hard issue some time soon.

In general we are going to try and have the conference calls every Wednesday
at 10 AM pacific time. For next week, we need to have it at 10 am Thursday
(not Wednesday). These times seems as good as any but if there is huge list
feedback that we need to pick a different time, I will move them. Thank you
Julian for staying up late for us west coast guys. I will send out
conference bridge information for these calls.

Elias will send out a list of the bugs we hope to cover in a given meeting.

Cullen

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Oct 2005 20:18:12 +0200

Thanks, Cullen.

For those who can use ics-over-http (such as with iCal or Mozilla 
Calendar), here's a calendar file:

	<http://greenbytes.de/tech/webdav/webdav.ics>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Oct 2005 20:42:26 +0200

Cullen Jennings wrote:
> ...
> ...

OK, here we go. I'd like to discuss the following issue...:

<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10>

which reads..:

-- start --

4.5: “The value of a property appears inside the property name element.
    The value may be any text, including valid XML.  When the value is
structured as XML, namespaces that are in scope for that part of the
XML document apply within the property value as well, and MUST be
preserved in server storage for retransmission later. Namespace prefixes
need not be preserved due to the rules of prefix declaration in XML.”

1) I think this needs to rephrased to use proper XML terminology, also
2) I think that namespace prefixes within the property value do need to
be roundtripped.

Proposal:

“The value of a property appears inside the property name element and
may be any kind of well-formed XML content, including both text-only and
mixed content. When the property value contains further XML elements,
namespaces and namespace prefixes that are in scope for that part of the
XML document apply within the property value as well, and MUST be
preserved in server storage for retransmission later.”

Update draft -05/06:

Issue 2 still needs to be resolved, the current text says: "Namespace
prefixes need not be preserved due to the rules of prefix declaration in
XML. This is incorrect because namespace prefixes *are* significant for
certain XML vocabularies, such as XSLT and XML Schema. So independantly
of what we decide for WebDAV, we should add an accurate statement about
what that means for arbitrary XML content in properties.

(Now in 4.4
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.4.4.p.5>))

-- end --

Proposed solutions:

(i) stick with the stated behaviour, but fix the explanation that 
misleadingly states that namespace prefixes are irrelevant,

or

(ii) state that namespace prefixes need to be preserved (such as in the 
text proposed by myself).

Further thought: depending on what standards status we aim for, we 
either need to think about what the protocol *should* be doing, or what 
current implementations actually do today. As far as I can tell, IIS 
doesn't preserve mixed content at all, while Apache/mod_dav does that 
(however it doesn't preserve prefixes; but maybe this can easily be 
fixed). I know that SAP Netweaver is preserving prefixes, and I 
*suspect* that Xythos does this as well (to be tested).

Feedback appreciated,

Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 05 Oct 2005 12:17:38 -0700

I'm not sure I understand what you mean by namespace preservation. Take the
example portion of some XML:

<h:html xmlns:xdc="http://www.xml.com/books"
        xmlns:h="http://www.w3.org/HTML/1998/html4">
 <h:head><h:title>Book Review</h:title></h:head>
 <h:body>
  <xdc:bookreview>
   <xdc:title>XML: A Primer</xdc:title>

Is it the "http://www.xml.com/books" that gets preserved or the "xdc". What
I'm trying to ask is if would be OK if the above XML got transformed to

<h:html xmlns:foo-xdc="http://www.xml.com/books"
        xmlns:h="http://www.w3.org/HTML/1998/html4">
 <h:head><h:title>Book Review</h:title></h:head>
 <h:body>
  <foo-xdc:bookreview>
   <foo-xdc:title>XML: A Primer</xdc:title>

I suspect you are saying this is not OK and the namespace prefix (ie the
xdc) needs to be preserved and not changed to foo-xdc. If this is what you
mean, then I am not sure what you mean by this is important for XSLT and XML
Schema, can you provide a bit more of an example.

Thanks for educating me on this - I'm not really going to end up with much
of an opinion on any of this but I am making sure I know enough to at least
understand the argument. Also, I suspect I might not be the only one of the
list that does not understand as much about XML as I wish I did :-)

Cullen

On 10/5/05 11:42 AM, "Julian Reschke" <[email-masked]> wrote:

> 4.5: ³The value of a property appears inside the property name element.
> need not be preserved due to the rules of prefix declaration in XML.²
> 
> ³The value of a property appears inside the property name element and
> preserved in server storage for retransmission later.²
> 
> Update draft -05/06:
>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 5 Oct 2005 12:38:44 -0700

IMPLEMENTORS -- can we get some sense of what existing server  
implementations do to preserve prefixes/namespaces in property values?   
If I recall correctly,  Xythos WFS preserves the namespaces but  
generates its own prefixes, and will frequently declare prefixes in  
another place.

so if a PROPPATCH contains
<D:prop xmlns:D="DAV:">
   <c:myprop xmlns:c="http://example.com/myclientnamespace">
     <x:value xmlns:x="http://example.com/anothernamespace/">text in  
here</x:value>
  </c:myprop>
</D:prop>

a subsequent PROPFIND might return

<D:prop xmlns:D="DAV:"  
xmlns:ns-1="http://example.com/myclientnamespace"  
xmlns:ns-2=http://example.com/anothernamespace/">
   <ns-1:myprop>
     <ns-2:value>text in here</ns-2:value>
  </ns-1:myprop>
</D:prop>

Lisa

On Oct 5, 2005, at 11:42 AM, Julian Reschke wrote:

> (ii) state that namespace prefixes need to be preserved (such as in  
> the text proposed by myself).
>
> either need to think about what the protocol *should* be doing, or  
> what current implementations actually do today. As far as I can tell,  
> IIS doesn't preserve mixed content at all, while Apache/mod_dav does  
> that (however it doesn't preserve prefixes; but maybe this can easily  
> be fixed). I know that SAP Netweaver is preserving prefixes, and I

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 5 Oct 2005 13:20:39 -0700

My DAV implementation (http://svn.red-bean.com/wsanchez/trunk/ 
TwistedDAV/) removes the property value element from the DOM in the  
request and creates a new XML document with that element as the new  
document's root element.  I let the PyXML engine render the new  
document and store the result in the property store for the resource.

   My intention is that when a client requests a property value, that  
the value sent back is semantically equal to the original. It is not  
character-for-character equal.  If you want that, don't send me XML,  
but escape your XML on the way in, and undo that on the way out.

   For example:

     <D:propertyupdate xmlns:D="DAV:" xmlns:A="http://apache.org/foo/">
     <D:set><D:prop><A:prop0><A:value0/></prop0></D:prop></D:set>
     </D:propertyupdate>

   May come back as:

     <D:multistatus xmlns:D="DAV:">
       <D:response>
         <D:href>/foo/</D:href>
         <D:propstat>
           <D:prop>
            <prop0 xmlns="http://apache.org/foo/"><value0/></prop0></ 
D:prop>
           </D:prop>
           <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
       </D:response>
     </D:multistatus>

   I just jiggered that by hand, so the XML may be error-prone, but I  
think the idea should get across.

   Personally, I found the whole notion of preserving XML semantics  
to be quite annoying; it basically means that all of my (dead)  
property storage has to be XML, or I have to tag them as to whether  
they are or aren't XML, but that's even more complexity.

   I'd prefer that XML not be allowed in property values at all.  If  
the values were always CDATA, then the server wouldn't ever have to  
do anything with them at all, which is far more appropriate, I  
think.  And you could always put XML in there escaped as CDATA and  
parse it when you get it back if you need to.  That would require you  
to do what Julian is expecting, which is to make XML in property  
values self-contained and eliminates any ambiguity about who is  
responsible for ensuring that (which I agree should be the client,  
but don't agree that the current spec says so).

     -wsv

On Oct 5, 2005, at 12:38 PM, Lisa Dusseault wrote:

> implementations do to preserve prefixes/namespaces in property  
> values?  If I recall correctly,  Xythos WFS preserves the  
> namespaces but generates its own prefixes, and will frequently  
> declare prefixes in another place.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Oct 2005 23:50:13 +0200

> but escape your XML on the way in, and undo that on the way out.

So who decides what "semantically equal" means? Is it semantically equal 
if it does a differing XML Infoset 
(<http://www.w3.org/TR/xml-infoset/>)? I doubt so.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Oct 2005 23:47:27 +0200

> Schema, can you provide a bit more of an example.

The namespace URI definitively needs to preserved, I don't think there's 
any question about that.

What this issue is about is whether if it's a problem to get

	<xyz:title xmlns:xyz="http://www.xml.com/books">XML: A Primer</xyz:title>

or

	<title xmlns="http://www.xml.com/books">XML: A Primer</title>

instead.

*Usually* that doesn't make a difference, and in a perfect world, it 
never would. Unfortunately, this isn't a perfect world and a long time 
ago, XML vocabularies have started to leak prefixes into text content 
and attribute values.

Consider:

	<xsl:template match="D:propfind" xmlns:D="DAV:">

In this case, loosing the "D" prefix actually breaks the semantics of 
the document, such as in:

	<xsl:template match="D:propfind" xmlns:ns0="DAV:">

This is an example from XSLT/XPath, similar cases can be constructed 
with documents that use XML Schema, such as in

	<count xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xsi:type="xs:integer">123</count>

For the record, the XML Infoset spec includes prefixes.

So no, rewriting namespace prefixes is *not* without problems, and 
*will* break semantics of XML content. Thus, we should either require 
prefixes to be preserved, or at least state that this part of the XML 
Infoset may not round-trip through WebDAV properties.

> list that does not understand as much about XML as I wish I did :-)

Sure :-)

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 5 Oct 2005 15:12:52 -0700

This is a great argument for a from-scratch design, and I understand it 
and would agree with it were we starting from a clean slate.  However, 
we're not starting from a clean slate.

  * Existing clients have to handle servers that do prefix replacement.  
An existing client would not benefit from more stringent rules in 
RFC2518bis until most servers are upgraded and satisfy the new 
requirements.  (Yes I'm aware this is a general concern with spec 
changes but it should still factor into this trade-off calculation)
  * Existing servers probably don't preserve prefixes, by and large.  
Requiring so many existing implementations to change is quite a burden. 
  For some of them this will involve performance considerations.
  * I'm unaware of any actual interoperability problems that have arisen 
in ordinary usage that require prefix preservation.  The template 
example is certainly a theoretical problem I agree.

We might consider WSanchez's idea of recommending that clients create 
self-contained XML fragments  and escape with CDATA, if the client is 
concerned about prefix preservation.  Otherwise, unprotected XML 
fragments are subject to server rewriting (whitespace as well as prefix 
selection).  This seems like a more practical approach starting from 
where we are now, and I think it handles all the cases with less spec 
changes.

Lisa

On Oct 5, 2005, at 2:47 PM, Julian Reschke wrote:

> The namespace URI definitively needs to preserved, I don't think 
> there's any question about that.
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 5 Oct 2005 20:21:22 -0400

Julian's argument was:
> Thus, we should either require 

It appears that Lisa and Wilfredo do not like the first alternative, so
let's explore the second alternative.  I believe Julian is just saying 
here
that the specification should warn clients and servers about the negative
consequences of not round-tripping namespace prefixes (so that clients are
prepared to handle the negative consequences).  Does anyone object to this
being added?  If not, Julian, could you write up what you'd like to be 
said
here (I assume it would be something like what you say below)?  Also, one
could add guidance to a client that they escape the XML if they are 
concerned
about the non-round-tripping of namespace prefixes.

Cheers,
Geoff

> > > I suspect you are saying this is not OK and the namespace prefix (ie 

> > the
> > > mean, then I am not sure what you mean by this is important for XSLT 

> > and XML

> >> Thanks for educating me on this - I'm not really going to end up with 

> >> much
> >> of an opinion on any of this but I am making sure I know enough to at 

> >> least

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 5 Oct 2005 18:04:02 -0700

Honestly, I don't really know, 'cuz I'm not an XML guy.  But this  
is exactly why:

     A) XML isn't nearly as easy as it's hyped up to be
     B) We shouldn't allow XML elements in property values

     -wsv

On Oct 5, 2005, at 2:50 PM, Julian Reschke wrote:

> So who decides what "semantically equal" means? Is it semantically  
> equal if it does a differing XML Infoset (<http://www.w3.org/TR/xml- 
> infoset/>)? I doubt so.
>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 5 Oct 2005 22:02:34 -0700

That works for me, unless more feedback from implementors comes up 
quite different.

Based on Julian's rewriting plus the discussion so far, here's some 
proposed wording:

The value of a property appears inside the property name element. The 
value
can be any kind of well-formed XML content: element content, text or 
mixed
content. When the property value contains element or mixed content,
namespaces that are in scope for that part of the XML document apply 
within
the property value as well, and servers MUST preserve namespaces in 
server
storage for retransmission later.  The server MAY preserve namespace 
prefixes
and non-significant whitespace.

For any values where specific prefix choices or whitespace matter (e.g. 
property
values containing XPath with prefixes), clients might need to force the 
server to
store the exact property value by encapsulating the value in a CDATA 
section.

Lisa

On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote:

>  > >> I'm not sure I understand what you mean by namespace 
> preservation.
>  > >> Take the
>  > >> I'm trying to ask is if would be OK if the above XML got 
> transformed
>  > >> to
>  > > > xdc) needs to be preserved and not changed to foo-xdc. If this 
> is
>  > > what you
>  > >> understand the argument. Also, I suspect I might not be the only 
> one
>  > >> of the

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Oct 2005 06:39:40 +0200

Wilfredo Sánchez Vega wrote:
>   Honestly, I don't really know, 'cuz I'm not an XML guy.  But this  is 
> exactly why:
> 

A) Yes.

b) Well. 6 years too late.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 6 Oct 2005 11:46:18 -0700

+1

- Jim

On Oct 5, 2005, at 5:21 PM, Geoffrey M Clemm wrote:

> let's explore the second alternative.  I believe Julian is just  
> saying here
> being added?  If not, Julian, could you write up what you'd like to  
> be said
> > > > xdc) needs to be preserved and not changed to foo-xdc. If  
> this is
> > > what you
> > >> understand the argument. Also, I suspect I might not be the  
> only one
> > >> of the

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 06 Oct 2005 21:05:32 -0700

Thanks for the good explanation - I get it now. What a nightmare.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Oct 2005 15:21:04 +0200

Lisa Dusseault wrote:
> That works for me, unless more feedback from implementors comes up quite 
> different.
> 
> The value of a property appears inside the property name element. The value
> can be any kind of well-formed XML content: element content, text or mixed
> namespaces that are in scope for that part of the XML document apply within
> the property value as well, and servers MUST preserve namespaces in server

s/namespaces/namespace names/

> and non-significant whitespace.

1. Of course it *may* preserve namespace prefixes. I think this needs to 
be rephrased the other way around: clients MUST NOT rely on prefixes 
being preserved since some servers won't do that.

2. I don't understand the part about non-significant whitespace. Why was 
it introduced, and what issue does that resolve????

> store the exact property value by encapsulating the value in a CDATA 

This is a bit misleading as it kind of suggests that this would allow to 
  use mixed or element content while preserving prefixes, which is not 
the case. Using CDATA will just result in the property value being a 
plain string, not tags.

Thus my preference still is to require servers to do the right thing. If 
we don't, the warning needs to be rephrased for example like this:

"Servers are not required to preserve namespace prefixes in property 
content, hence clients should not rely on them being preserved.  If 
preservation of prefixes is required (such as in XPath expressions), 
then it should be considered to use a different format for the value, 
such as plain text containing escaped XML)."

Best regards,

Julian

---

From: Elias Sinderson <[email-masked]>
Date: Thu, 13 Oct 2005 11:10:39 -0700

Cullen Jennings wrote:

>Elias kindly volunteered to collect all the know issues and put them in bugzilla.
>
I've added all of the 'open' issues listed at 
<http://www.webdav.org/wg/rfcdev/issues.htm> -- TBD how to handle issues 
marked as 'edit', 'InBis', '2518bis', 'Version2', or 'closed'.

>He is going to tell us how he will mark in bugzilla two different states. One state is when the WG agrees on general way to resolved the issue but has not updated drafts yet or figured out exact text, and other state is
I actually see a need for more than two states: New, Assigned (accepted 
by WG for discussion), Resolved (some resolution reached on the list, 
editorial or otherwise), Closed (resolution is in current draft). Comments?

Cheers,
Elias

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 13 Oct 2005 11:29:53 -0700

There are some language changes proposed by Julian that I'm OK with,  
but it's clear we're thinking a little differently about whitespace --  
read down a bit for that discussion and questions for client and server  
implementors.

> s/namespaces/namespace names/
Sure.

> 1. Of course it *may* preserve namespace prefixes. I think this needs  
> to be rephrased the other way around: clients MUST NOT rely on  
> prefixes being preserved since some servers won't do that.
I don't mind either way of wording this.

>
> 2. I don't understand the part about non-significant whitespace. Why  
> was it introduced, and what issue does that resolve????
First assumption: that there is non-significant whitespace, based on  
reading the XML recommendation

For example, if my property name value in PROPPATCH request is

	<D:myprop xmlns:D="DAV:">
		<myvalue xmlns="http://example.org/schema">
			<stuff/><morestuff/>
		</myvalue>
	</D:myprop>

Then in this case, I believe all line returns and tabs introduced here  
are non-significant.

Second assumption:  that a server might strip non-significant  
whitespace either at the beginning or end of the property value if it's  
a XML value.  So a server could return in a PROPFIND response:

	<D:myprop xmlns:D="DAV:"><myvalue xmlns="http://example.org/schema">
			<stuff/><morestuff/>
		</myvalue></D:myprop>

(Conversely, a server could *add* whitespace in the locations I just  
removed whitespace.)

Third assumption/evaluation: that a server might reasonably strip  
non-significant whitespace in the *middle* of an XML property value.   
So a server could also return

	<D:myprop xmlns:D="DAV:"><myvalue  
xmlns="http://example.org/schema"><stuff/><morestuff/></myvalue></D: 
myprop>

(if this line wraps in your email reader, it was intended to be a  
single line with no returns)

Why might a server do this?  If XML property values were stored as XML  
trees for fast searching and processing, then the text representation  
of the value could be reconstructed easily if whitespace did not need  
to be preserved exactly as is.

If these assumptions are wrong or there's consensus that whitespace  
rewriting is unreasonable, then I'd have to rewrite this text.

IMPLEMENTORS: Do any servers rewrite whitespace in or before or after  
property values?  Do any client implementors have assumptions either  
way about this?

>
>> For any values where specific prefix choices or whitespace matter  
>> (e.g. property
>> values containing XPath with prefixes), clients might need to force  
>> the server to
> This is a bit misleading as it kind of suggests that this would allow  
> to  use mixed or element content while preserving prefixes, which is  
> not the case. Using CDATA will just result in the property value being  
> a plain string, not tags.
>
> Thus my preference still is to require servers to do the right thing.  
> If we don't, the warning needs to be rephrased for example like this:
>

Sure, I can call it plain text.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2005 21:07:03 +0200

> Then in this case, I believe all line returns and tabs introduced here  

But they are. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.4.4.p.7>:

"The XML attribute xml:space MUST NOT be used to change white space 
handling. White space in property values is significant."

> (Conversely, a server could *add* whitespace in the locations I just  

That would be a bug according to the current draft.

> rewriting is unreasonable, then I'd have to rewrite this text.

Actually what I'm asking for is that we don't change the text unless 
there clearly is a consensus to do so. The current spec says whitespace 
is significant, and as far as I can tell, nobody has asked for a change 
of that.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 13 Oct 2005 12:12:07 -0700

On Oct 13, 2005, at 12:07 PM, Julian Reschke wrote:

> there clearly is a consensus to do so. The current spec says 
> whitespace is significant, and as far as I can tell, nobody has asked 
> for a change of that.
>

Fair enough, although now I'm thinking we should be specific about XML 
values, and about the beginning/end of the value as well as the middle. 
  I was thinking that the existing text in 2518 applied only to text 
property values.

I'm still very curious to hear what implementations do/assume; that's 
good input to see if the consensus is consistent with the spec.

lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2005 21:36:02 +0200

>  I was thinking that the existing text in 2518 applied only to text 

 From <http://www.webdav.org/wg/rfcdev/issues.htm>:

--
107
	
IS_XMLSPACE_SIGNIFICANT
	
Edit
	
InBis
	
Should the xml:space attribute be respected.� 2518bis on 6/1/02 says it 
should not. There is some debate on this.
	
Re-raised: 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.html
	
The conclusion of the May/June 2002 discussion was that white space is 
significant: 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html
--

So the old issues list says this was discussed, that there was 
consensus, and that rfc2518bis has been changed accordingly.

If you want to re-open the issue, please do so (but in a different 
thread). If you do, please make sure to clarify what was wrong the 
resolution we reached back then.

> good input to see if the consensus is consistent with the spec.

Do you have any data about servers that get that wrong? That would be 
interesting indeed.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 13 Oct 2005 13:12:27 -0700

I guess what's giving me so much cognitive dissonance here is that 
prefixes now are not preserved but whitespace is.  That seems 
inconsistent to me -- if some XML rewriting is OK but other XML isn't, 
what's the difference.

Lisa

On Oct 13, 2005, at 12:36 PM, Julian Reschke wrote:

>>> whitespace is significant, and as far as I can tell, nobody has 
>>> asked for a change of that.
>>>
>> Fair enough, although now I'm thinking we should be specific about 
>> XML values, and about the beginning/end of the value as well as the 
>> middle.  I was thinking that the existing text in 2518 applied only 
>> to text property values.
>
> Should the xml:space attribute be respected.╴ 2518bis on 6/1/02 says 
> it should not. There is some debate on this.
> 	
> Re-raised:

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2005 22:29:07 +0200

> inconsistent to me -- if some XML rewriting is OK but other XML isn't, 

Well. Both are part of the XML Infoset and the XPath model, so there are
two independant W3C specs that consider them significant. That's why I'd
like servers to preserve both.

Maybe we should reconsider the issue? I think we have three servers
(SAP|Xythos|moddav) that can handle XML at all, so if there's a minimum
chance we can get all of them to preserve prefixes, we should just make
that the requirement.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Oct 2005 11:52:52 +0200

> editorial or otherwise), Closed (resolution is in current draft). Comments?

Whatever works for you.

Related: I'd like to propose that we use the mailing list to *discuss* 
issues; that will make things much more readable. Once the WG reaches 
consensus on an issue, the proposed resolution can be entered in 
BugZilla, and then the current author of rfc2518bis can update the spec.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 15 Oct 2005 22:05:14 +0200

OK,

in the meantime I have tested round-tripping of property values (using
the attached script). Results for those servers I can currently test with:

SAP Netweaver: preserves whitespace and namespace prefixes

Apache/moddav 2.0.54: preserves whitespace, but not namespace prefixes.

Xythos (whatever release currently running on www.sharemation.com):
preserves whitespace, but not namespace prefixes. Note that is also
looses attributes in the property value (!).

IIS - will need to test: AFAIR, no mixed content supported at all.

So yes, those servers that do support mixed content also preserve
whitespace.

Assuming that IIS is broken anyway (and is not going to be fixed anytime
soon), we could potentially concentrate on Xythos and Apache/mod_dav.
Xythos will need a fix for attribute rounbd-tripping anyway. Regarding
mod_dav, maybe a fix for the missing prefix round-tripping is simple
(anybody listening? Joe?).

Best regards, Julian

---

From: Joe Orton <[email-masked]>
Date: Sun, 16 Oct 2005 09:35:58 +0100

> (anybody listening? Joe?).

I don't think it would be particularly simple, no; the assumption that 
the prefix names don't need to be preserved is quite deep-rooted in 
mod_dav's property handling.

joe

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 17 Oct 2005 17:20:17 -0400

Lisa,

Based on my reading of the book "Effective XML"
(http://www.cafeconleche.org/books/effectivexml/)

Item 10: White space matters

  WebDAV servers should preserve the white spaces
  when the attribute "xml:space" is set to "preserve".
  Else, if "xml:space" is not set or set to "default"
  "the application may treat white spaces in the
  element in whatever fashion is customary for that
  application".

Item 21: Rely on namespace URIs, not prefixes

  A WebDAV server should be allowed to change any
  namespace prefix.  "It's the URI that counts,
  not the prefix".

BTW, I highly recommend reading "Effective XML" to
anyone that works with XML.

Cheers,
Bernard

Lisa Dusseault wrote:
>             Actually what I'm asking for is that we don't change the
>             text unless there clearly is a consensus to do so. The
>             current spec says whitespace is significant, and as far as I
>             can tell, nobody has asked for a change of that.
> 
>         Fair enough, although now I'm thinking we should be specific
>         about XML values, and about the beginning/end of the value as
>         well as the middle. I was thinking that the existing text in
>         2518 applied only to text property values.
> 
> 
>     The conclusion of the May/June 2002 discussion was that white space
>     is significant:
>         I'm still very curious to hear what implementations do/assume;
>         that's good input to see if the consensus is consistent with the
>         spec.
> 
> 
>     Do you have any data about servers that get that wrong? That would
>     be interesting indeed.
> 
>     Best regards, Julian
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Oct 2005 11:55:24 -0700

Do I have the summary right that there is only one server we know of that
preservers namespaces?

On 10/15/05 1:05 PM, "Julian Reschke" <[email-masked]> wrote:

> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited
> by this policy. The attachment has been removed from this message and
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
> 
> * This unique quarantine identifier: j9FK5Nuh008046
> 
> If the matter is urgent, you may follow up by calling one of the below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as it
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2005 23:26:45 +0200

>   namespace prefix.  "It's the URI that counts,

It's the W3C who started to treat prefixes as significant; so even
though it may have been a bad idea in the first place, the cat is out of
the bag. Note that prefixes are also part of the most widely used XML
data models (DOM, XPath, XML Infoset).

Best regards,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2005 23:32:15 +0200

> Do I have the summary right that there is only one server we know of that

One that preserves namespace URIs and namespace prefixes (SAP), two 
others that only preserve namespace URIs (Apache/mod_dav and Xythos).

Best regards, Julian

---

From: Brian Moseley <[email-masked]>
Date: Thu, 20 Oct 2005 14:01:36 -0700

> Do I have the summary right that there is only one server we know of that

has anybody created a test case to use in checking server behavior for 
preserving whitespace and namespaces? if so, i'll use that to give you 
results for cosmo. otherwise i'll whip up something of my own.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Oct 2005 23:24:14 +0200

> results for cosmo. otherwise i'll whip up something of my own.

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

Best regards, Julian

---

From: Brian Moseley <[email-masked]>
Date: Thu, 20 Oct 2005 15:00:16 -0700

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

ah, no windows here so i'll go ahead and write my own. thanks!

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2005 21:59:54 +0200

Hi,

in the meantime (conference call), we found that there was a
misunderstanding between Lisa and myself. When I talked about
"whitespace", I was talking about whitespace in text nodes (between
tags), while she thought I was talking about whitespace inside tags.

To clarify: whitespace inside tags (such as the one between attributes)
is not significant. Nor is attribute order for that matter.

In the conference call, we kind of agreed to delegate terminology to one
of the applicable W3C documents/data models (such as XPath or XML
Infoset). Funny enough, this is exactly what I have proposed long LONG
(!) ago:

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0102.html>

Best regards, Julian