Re: [XML] well-formedness & validation / section 4.2.8.1

> Right. No minimum "guarantee".
> That is where I think that a SHOULD binding
> is strong.

Since SHOULD is not an absolute requirement (the exit clause basically states that one must just have a good excuse for not following the SHOULD), a MUST for well-formedness does ensure a minimum guarantee for the correctness of the content delivered to terminals. And that is what needed: at least it is syntactically correct, it will not make an XML parser bomb.

> I do not understand the contradiction. I am
> saying well-formedness and validation are 
> equally strong.

The point is to have well-formedness stronger than validation -- well-formed=basic requirement to be always fulfilled, validation=higher requirements that should, but may not, be fulfilled.

> I follow your point, just does not see why
> it is so important. What I mean is that I 
> do not think that any CT-proxy wants to
> produce content that breaks the rendering 
> on mobile phones, and is likely to take
> care of that by itself.

It is the issue. Deployed CT-proxies do not "want" to deliver incorrect content to terminals -- but I have experienced just such situations. Deployed CT-proxies do not "want" to ignore no-transform directives -- but they do. Deployed CT-proxies do not "want" to err when dealing with character encodings -- but I have seen them do so.

There are no such things as implicit requirements in a normative document. We must put the dots on the i and cross all t if we want some specific behaviour to be actually respected and testable in ICS -- well-formedness being such a requirement that has been a long-standing one, as the document survey I made demonstrates.

E.Casais