- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 29 May 2002 09:11:18 +0200
- To: "Jason Crawford" <ccjason@us.ibm.com>, "Babich, Alan" <ABabich@filenet.com>
- Cc: <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Wednesday, May 29, 2002 12:18 AM > To: Babich, Alan > Cc: w3c-dist-auth@w3c.org > Subject: RE: xml:space > > > > << > 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. How do you decide that it only consists of tags (element content), if it *does* include whitespace? > 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 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 > isn't familiar with an incoming property, > they need to treat non tagged values in a way that preserves spaces. This *all*. > also applies to known properties where there are > signficant reasons why the spacing should not be altered. > > Right? 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.
Received on Wednesday, 29 May 2002 03:12:25 UTC