W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [widgets] white space handling

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Mon, 21 Dec 2009 09:43:07 +0100
Message-ID: <4B2F351B.2070804@enst.fr>
To: Robin Berjon <robin@berjon.com>
CC: public-webapps <public-webapps@w3.org>
Hi Robin,

Le 18/12/2009 18:01, Robin Berjon a écrit :
> On Dec 18, 2009, at 16:36 , Cyril Concolato wrote:
>> Le 18/12/2009 15:58, Robin Berjon a écrit :
>>> P+C doesn't tie processors to a particular version of XML, and lists its white space characters accordingly (and defensively). If you're certain that you will only ever get content that comes from a conforming XML 1.0 implementation, then you probably don't need to check for this.
>> I don't read it like that. P&C explicitely references XML 1.0 and never mentions 1.1. So I thought the behavior was conformant to 1.0. It's fine if the spec also handles 1.1 but it should be mentioned. Also the rationale for the choices of space characters should also be indicated and the differences between XML 1.0 and XML 1.1 should be present.
> I beg to differ. I think that we should build specifications that can handle future changes to the stack
I'm fine with that.

> without listing all the versions that are supported.
It's not because you cite what you support that you're restricted to that. I think it helps understanding a spec.

> P+C is built for XML 1.0, and it's great that it has the resilience to handle changes to 1.1 without a hitch — but who knows what XML 4.2 might add? We can't guarantee that it'll work, but we can try (and if it does work, I don't think that we should list it either). I certainly don't think that it's the right place to document potential differences between versions of XML — as your XHTML example shows, that kind of information goes stale.
If you're explicitely citing dated version of the spec, since they're cast in stone, I don't see how they can go stale.

> Furthermore, I didn't say that the differences between XML 1.0 and 1.1 are the rationale for this choice — I was merely indicating that using 1.1 you could get such characters and that P+C's robustness against that was a plus. I wasn't in Marcos's brain when that part was written but my specification exegesis antennae suspect that the listed class of characters corresponds to the Unicode white space character class (and therefore to what Unicode-aware processors would consider white space, notably \s in regular expressions).
Well, you know my concern. I want to understand the spec in order to implement it properly. I'm not asking for any new normative statement, nor any change to the existing ones. I would be fine with informative notes explaining the intents of some choices. For example, as you know, I'm implementing an SVG UA and an P&C UA, I want to know what's reusable, what's common without doing XML archaeology. Such notes would help me and I suspected it would help others. Nothing more.


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
Received on Monday, 21 December 2009 08:43:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC