W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

RE: xml:space

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>
Message-ID: <JIEGINCHMLABHJBIGKBCAEMGEKAA.julian.reschke@gmx.de>

> 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


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:25 UTC