RE: [CTG] Draft 2008-11-07 / inconsistencies / validation

> Can we state that the transformed content returned to the terminal
must at least be well-formed (following XML terminology)?

This would certainly be an aspiration, as it may make life easier for
further adaptive processes such as plug-ins or assistive technology.
However, once again (sadly, bordering on shame) there are even cases
where devices might not behave as expected unless some "well-formedness"
rules are broken. There are devices that sometimes have trouble with
body-less tags whose "/" is not preceded by a space. For example, <br>
and <br /> are ok, but <br/> causes issues. (I think internally the
parser miss-interprets the element name as "br/".) So being well-formed
is not always a guarantee that the browser/device will accept your
content.

I think the best advice we can offer is to produce well-formed and
standards compliant content where possible, and only to deviate from
these where support for the standards has already been compromised by
the requesting device.

Basically, if you deviate from the standards, you better have a good
reason for doing so. Being sloppy is no excuse.

---Rotan

(Note, in the case of HTML instead of XHTML, we must be careful not to
demand XML well-formedness for a language that is not actually XML.)

-----Original Message-----
From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of Eduardo Casais
Sent: 11 November 2008 12:17
To: public-bpwg-ct@w3.org
Subject: RE: [CTG] Draft 2008-11-07 / inconsistencies / validation


> Consequently, in order to satisfy the need to give
> excellent end-user experiences, we must (sadly) adjust
> our adapted output to suit the quirks of the requesting
> device, thus addressing the bugs/features that
> we know to be present.

You are actually raising two points:
a) extensions to existing standards (i.e. additional features that are
not captured by standard W3C, IETF, etc formal specifications);
b) errors, i.e. deviations from the supposedly supported formal
specifications.

Regarding point (a), vendors usually make available a formal definition
of their extended features (otherwise how would developers use them?),
but we can admit that there is no general guarantee that there is a
published formal specification that can be used for validation.

Regarding point (b), you are thinking about issues like, say, a browser
that accepts <p> inside <div> but not otherwise, although this is
possible as per (X)HTML DTD. This is the nasty part, and I agree this is
usually deduced from  testing, not from some formal spec. 

Can we state that the transformed content returned to the terminal must
at least be well-formed (following XML terminology)?

E.Casais

Received on Tuesday, 11 November 2008 12:40:50 UTC