Subject: RE: XML InfoSet and property value preservation

From: "Lukas Mathis" <[email-masked]>
Date: Thu, 17 Nov 2005 08:48:04 +0100

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

I agree with that. It's XML, and it should be treated as such. If the client wants it be treated as text, it must but it in a CDATA section.

lucas

-- 
Lukas Mathis, Numcom Software AG
Hardturmstrasse 66, CH-8005 Zürich
Direct +41(0)43-204 06 08
mailto:[email-masked], http://www.numcom.com/

---

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

> I agree with that. It's XML, and it should be treated as such. If the client wants it be treated as text, it must but it in a CDATA section.

I agree with that too. As a matter of fact, I don't think anybody 
disagrees here.

Best regards, Julian

---

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

Wilfredo Sánchez Vega wrote:
>   Except that I think attempting to preserve namespace prefixes in 
> property XML falls in that category.
> 
>   Namespace prefixes aren't supposed to be semantically meaningful, and 
> changing them shouldn't have any more effect on the XML reader than 
> changing a variable name in code should on a program.  What matters is 
> the data being referred to, not the name of the reference.

Wilfredo,

it would be helpful if you go through the mailing list archives and 
re-read the thread.

I absolutely do agree that namespace prefixes were not *meant* to be 
significant, but now they are, because people (incl. the W3C) have 
started putting them into attribute *values*, such as in XPath or XML 
Schema.

Was that a bad idea? Probably yes.
Can we change that? No.

Best regards, Julian

---

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

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

> Lukas Mathis wrote:
>>>     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.
>> I agree with that. It's XML, and it should be treated as such. If  
>> the client wants it be treated as text, it must but it in a CDATA  
>> section.
>

    Namespace prefixes aren't supposed to be semantically meaningful,
and changing them shouldn't have any more effect on the XML reader
than changing a variable name in code should on a program.  What
matters is the data being referred to, not the name of the reference.

	-wsv

---

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

Wilfredo Sánchez Vega wrote:
>   Right, but the fact is that XML parsing libraries don't generally 
> preserve prefix names.  So I agree that those were bad ideas.

What do you mean by generally? DOM - as far as I can tell the only XML 
API with an W3C stamp on it - preserves them. So does SAX.

In fact, building a compliant XSLT processor on top of an API does 
require that.

>   So unless the XML spec is going to change to require parsers to 
> preserve prefix and we can require XML parsers to comply with the 

The XML spec requires that.

> updated XML spec, I don't think it's reasonable to expect a server to 
> preserve prefixes.  Doing so requires the server author to use an XML 

With all due respect, I think you need to check the facts.

> library that does more than the XML spec requires, which may mean they 
> have to write their own.  If you can't use a standard XML library, 
> you're obviating the main advantage of using XML at all.
> 
>   If you need to preserve prefixes, regardless of what your reasons are, 
> including your use of other (perhaps poorly thought out) W3C specs, you 
> are in effect expecting the server to treat your XML as text.  If that's 
> the case, then encode the property XML as text and be done with it.  I 
> don't really follow why this isn't considered a viable option here.

Wilfredo,

I think you're arguing based on a misunderstanding of XML. The XML spec 
itself doesn't say anything about the prefix in a name being ignorable 
(as a matter of fact, it doesn't speak of prefixes at all, because 
that's in the Namespaces spec). Nor does the XML Namespaces spec itself. 
Nor does DOM, XPath or XSLT. Or SAX (for an example of a non-W3C API).

Best regards, Julian

---

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

On Nov 17, 2005, at 12:16 PM, Julian Reschke wrote:

> I think you're arguing based on a misunderstanding of XML. The XML  
> spec itself doesn't say anything about the prefix in a name being  
> ignorable (as a matter of fact, it doesn't speak of prefixes at  
> all, because that's in the Namespaces spec). Nor does the XML  
> Namespaces spec itself. Nor does DOM, XPath or XSLT. Or SAX (for an  
> example of a non-W3C API).

   Not saying anything isn't the same as requiring that they be  
preserved, but OK.

   I get my impression from the following.  Here is some input XML:

<D:propertyupdate xmlns:D="DAV:" xmlns:L="http://webdav.org/neon/ 
litmus/">
<D:set><D:prop><prop0 xmlns="http://webdav.org/neon/litmus/">value0</ 
prop0></D:prop></D:set>
<D:set><D:prop><prop1 xmlns="http://webdav.org/neon/litmus/">value1</ 
prop1></D:prop></D:set>
<D:set><D:prop><prop2 xmlns="http://webdav.org/neon/litmus/">value2</ 
prop2></D:prop></D:set>
<D:set><D:prop><prop3 xmlns="http://webdav.org/neon/litmus/">value3</ 
prop3></D:prop></D:set>
<D:set><D:prop><prop4 xmlns="http://webdav.org/neon/litmus/">value4</ 
prop4></D:prop></D:set>
<D:set><D:prop><prop5 xmlns="http://webdav.org/neon/litmus/">value5</ 
prop5></D:prop></D:set>
<D:set><D:prop><prop6 xmlns="http://webdav.org/neon/litmus/">value6</ 
prop6></D:prop></D:set>
<D:set><D:prop><prop7 xmlns="http://webdav.org/neon/litmus/">value7</ 
prop7></D:prop></D:set>
<D:set><D:prop><prop8 xmlns="http://webdav.org/neon/litmus/">value8</ 
prop8></D:prop></D:set>
<D:set><D:prop><prop9 xmlns="http://webdav.org/neon/litmus/">value9</ 
prop9></D:prop></D:set>
</D:propertyupdate>

   And here is a snippet in the Python interpreter that reads it and  
writes it back out:

 >>> doc = xml.dom.minidom.parseString(file("/Volumes/data/Users/ 
wsanchez/Developer/Python/Twisted/twisted/web2/dav/test/data/xml/ 
PROPPATCH_request.xml").read())
 >>> xml.dom.ext.Print(doc)
<?xml version='1.0' encoding='UTF-8'?><D:propertyupdate  
xmlns:D='DAV:' xmlns='http://webdav.org/neon/litmus/' xmlns:L='http:// 
webdav.org/neon/litmus/'>
<D:set><D:prop><prop0>value0</prop0></D:prop></D:set>
<D:set><D:prop><prop1>value1</prop1></D:prop></D:set>
<D:set><D:prop><prop2>value2</prop2></D:prop></D:set>
<D:set><D:prop><prop3>value3</prop3></D:prop></D:set>
<D:set><D:prop><prop4>value4</prop4></D:prop></D:set>
<D:set><D:prop><prop5>value5</prop5></D:prop></D:set>
<D:set><D:prop><prop6>value6</prop6></D:prop></D:set>
<D:set><D:prop><prop7>value7</prop7></D:prop></D:set>
<D:set><D:prop><prop8>value8</prop8></D:prop></D:set>
<D:set><D:prop><prop9>value9</prop9></D:prop></D:set>
</D:propertyupdate>

   I've done nothing other than ask my library to read the file and  
then render it back out.  Note that the "L" prefix was not merely  
modified, it was removed entirely.  Clearly the XML library I'm using  
here thinks it's OK to rewrite the XML.  Is this a bug?

	-wsv

---

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

Wilfredo Sánchez Vega wrote:
> ...
>   I've done nothing other than ask my library to read the file and then 
> render it back out.  Note that the "L" prefix was not merely modified, 
> it was removed entirely.  Clearly the XML library I'm using here thinks 
> it's OK to rewrite the XML.  Is this a bug?

No, it's not a bug. There is no standard whatsoever about what an XML 
API needs to provide. I even wrote a similar one for Java myself.

But that doesn't mean that "generally", APIs do not provide this kind of 
information.

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 17 Nov 2005 15:16:09 -0800

OK, my concern is that I'm going to want to use any compliant XML  
library to read and write my XML by asking my library to read the XML  
and then telling it to render the property elements back out.  I'd  
really like to avoid having to know much more about XML than that, as  
you've noticed.  ;-)

   If you want me to preserve the prefixes, I'm worried that I would  
then have to choose an XML library that's "WebDAV compliant" (XML  
plus X) rather than simply XML compliant, or write my own XML  
generator.  (You're right that the prefixes are available at parse  
time in both SAX and DOM, so the issue in this case in the XML  
renderer.)  That's a lot more work for the server author as compared  
to the client simply escaping the XML so as to guarantee that the  
server gives you back exactly what you gave it.

   What value is there in the server doing any parsing of dead  
properties in the first place?  I still see no good reason to give  
the server XML (which it *has to* parse, because it's part of the  
containing request document) in a dead property.  I realize that we  
allow it today, and can't take that away, but why go through hoops  
preserve XML data on the server when the client can very easily  
guarantee it by sending the XML as CDATA instead?

	-wsv

On Nov 17, 2005, at 1:14 PM, Julian Reschke wrote:

> No, it's not a bug. There is no standard whatsoever about what an  
> XML API needs to provide. I even wrote a similar one for Java myself.
>
> But that doesn't mean that "generally", APIs do not provide this  
> kind of information.