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

Yes, "<element />" is well formed, but what I was trying to say is that
well-formedness is not a sufficient condition. Requiring that you must
have a space before / means that well-formedness according to the
specification may not be well-formed with respect to what's acceptable
to the device. So running the content through a standard WF validator
doesn't necessarily give you the "all clear". To be fair, in general, WF
markup is accepted by all browsers and is highly recommended.

Validation, however, is another matter...

We've seen in the past where browser features could only be used when
some proprietary markup was employed. (The "<embed>" element from
Netscape 4 comes to mind.) We saw repeats of proprietary markup in
mobile devices with the *many* iterations of cHTML (later called iHTML).
These many versions are like XHTML-MP, but each with their own quirks
such as ilet and iswf attributes, and the <marquee> tag (as once
appeared in MS-IE). Then there's the proprietary tags in the Openwave
mobile browsers that we've all come to love.

Generally, mobile browsers do quite well when given valid markup (with
some edge-case restrictions) but often you can get an improved
experience by going a little beyond the boundaries. Not that I approve
of proprietary extensions! I can't be certain which of these browsers
come with formal DTDs/Schemas of their "improvements on the standards",
but I'd guess that requiring formal validation against an unavailable
formal definition could be asking too much. Essentially, through
experiment and determined detective work, we in the industry have
discovered various quirks that can transform an experience from
tolerable to pleasant, and that's what gets delivered. In theory one
could provide a validator for each quirky variant, but I doubt that's
realistic.

Don't get me started on adapting CSS...!

The bottom line, while I agree that well-formedness and validation
against standards are to be strongly recommended, in practical terms
making this mandatory is too much. Using the normative "MUST" would mean
that any solution that drifted even a tiny bit into the grey area to
deal with a quirky device would suddenly find itself non-compliant,
which is rather too much punishment for trying to improve the user
experience. (*)

---Rotan

(*) I must admit that this sounds a little like "the ends justify the
means" and I can't help thinking that this is the reality of our
industry.


-----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 13:08
To: public-bpwg-ct@w3.org
Subject: RE: [CTG] Draft 2008-11-07 / inconsistencies / validation


> 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.

Perhaps, but I have a hard time figuring out a concrete case for this,
since the example you give:

> 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.

raises no issue at all. An XML document formatted so that empty elements
are of the form <element /> is well-formed, according to the XML
specification:

[44]   	EmptyElemTag	   ::=   	'<' Name (S Attribute)* S? '/>'
[WFC: Unique Att Spec]

In this case, while there might be restrictions as to the instantiation
of the XML syntax, the result does satisfy the well-formedness
constraints of the standard.

What well-formed documents means for other types may be an issue though,
but if the concept is not even defined for a type, I doubt we can say
anything formal at all about the resulting documents (not even talking
about validity).

E.Casais

Received on Tuesday, 11 November 2008 15:36:45 UTC