Subject: RE: xml:space

From: "Jason Crawford" <[email-masked]>
Date: Tue, 28 May 2002 18:18:09 -0400

<<
Obviously, white space has to be significant in the values of string
properties, or it won't be interoperable.
Yup.  And conversely w.s. is probably not signficant in values that consist
only of tags.

And we don't need to make it significant in known properties like
getcontentlength where we
can probably deal with leading and trailing spaces.  Buf if a server/client
isn't familiar with an incoming property,
they need to treat non tagged values in a way that preserves spaces.  This
also applies to known properties where there are
signficant reasons why the spacing should not be altered.

Right?

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 29 May 2002 09:11:18 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Wednesday, May 29, 2002 12:18 AM
> To: Babich, Alan
> Cc: [email-masked]
> Subject: RE: xml:space
>
>
>
> <<

How do you decide that it only consists of tags (element content), if it
*does* include whitespace?

> can probably deal with leading and trailing spaces.  Buf if a

I think we should say that for these properties,

- servers SHOULD not send ignorable whitespace, and

- that servers SHOULD accept ignorable whitespace from clients (and then
we'll have to list those standard DAV: properties where ws is ignorable).

Alternatively, we could also say that ignorable WS never should be sent,
which would make the spec much simpler.

> server/client

*all*.

> signficant reasons why the spacing should not be altered.

Almost. I think the easist solution is to say that whitespace *always* is
signifcant (== ignorable whitespace SHOULD NOT be sent), and then possibly
allow some workarounds for old known DAV: properties if we need to avoid
breaking existing code.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 29 May 2002 10:56:32 -0700

> *does* include whitespace?

If an element is declared to contain PCDATA, like the depth element in
12.1.1 in RFC 2518, then whitespace is important. If an element is declared
to contain other elements, e.g. activelock in 12.1 of RFC2518, then
whitespace around the contained elements is removable according to the rules
of XML parsing.

If an element is not recognized, typically it is ignored.  However, WebDAV
properties may be retrieved which are not recognized elements, it is not
known whether they are supposed to contain elements or text, and yet it is
still desirable to display to the user.  In this case, a couple heuristics
may help:
 - if the value contains unescaped < after some white space, it probably
contains XML elements, and the whitespace before the < and after the end of
the value can be removed.  However you must recurse and make the same
evaluation before removing internal whitespace.
 - if the value begins with "<![CDATA[", the whitespace before it can be
removed.
 - Otherwise white space is crucial.

E.g.
<foo1>  <whitespace-can-be-removed/>  </foo1>
<foo2>  <![CDATA[Whitespace inside CDATA is important, but outside isn't]]>
</foo2>
<foo3>  All this whitespace is important.  </foo3>

Your XML parser should be able to do this for you.  E.g. a DOM parser will
return a regular element as the child of foo1, automatically stripping
whitespace, and a text thing as the child of foo3 with whitespace preserved.

> which would make the spec much simpler.

I don't think so. That would make requests/responses hard to debug. In
practice, it's very helpful to have line returns and tabs to make XML easier
to read.  It would also be adding rules on top of XML, to little purpose.
Finally, it would be very difficult to put examples in specification text
that conformed to this rule.

> allow some workarounds for old known DAV: properties if we

No, we should follow the XML rules for where whitespace is significant.
According to those rules, whitespace is significant inside our date and
content length (integer) properties, inside depth elements, etc.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 29 May 2002 22:55:13 +0200

Lisa,

I don't agree at all.

First of all, whitespace is only available if a DTD tells you that this is
the case. If you don't know an element, there's no reliable way to tell
whether it's ignorable or not.

Whether CDATA is present or not isn't relevant at all. It's just a markup
construct that allows the (human) author of an XML file not to escape the
special characters "<", ">", "&" and the quote characters.

> <foo3>  All this whitespace is important.  </foo3>

In each case I can construct a case where the opposite is true.

Finally,

> content length (integer) properties, inside depth elements, etc.

Yes we should to that. And in XML, you can't ignore whitespace unless you
have a validated file and a DTD which tells you where whitespace is
ignorable.

> -----Original Message-----
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Wednesday, May 29, 2002 7:57 PM
> To: 'Julian Reschke'; 'Jason Crawford'; 'Babich, Alan'