W3C home > Mailing lists > Public > www-tag@w3.org > December 2008

Re: ZIP-based packages and URI references into them ODF proposal

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 30 Dec 2008 11:22:59 +0100
Message-ID: <4959F683.1030308@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>

Ian Hickson wrote:
> ...
> Yes, HTML has a terrible forward-compatibility story. We have ended up 
> forced into this situation mostly because the earlier versions of the spec 
> didn't define the full processing model, and thus user agents varied 
> greatly in their behavior. Thus, instead of a coherent, well-thought-out 
> extension model, we have a de-facto extension model derived from a long 
> series of accidental decisions by a wide variety of independent people.
> 
> This is another example of what happens when specifications don't have 
> clear and fully defined processing models.
> ...

So why doesn't HTML5 fix this, for instance by stating that the void 
elements are exactly those defined in HTML4, and every future element 
will be non-void?

> ...
> The key part is "the XML processor MAY report the error or MAY recover by 
> ignoring the attribute specification or by reporting the (erroneous) value 
> to the application". This is the three options I gave above -- report an 
> error, ignore the error, or report the value to the next level and let it 
> deal with it however it wants, i.e. interpret and "correct" it. That isn't 
> going to lead to interoperability. Some UAs will have fatal error 
> handling, some will ignore it, some will "correct" it and treat it as 
> 'preserve', some as 'default', some maybe as yet something else -- and all 

..."correcting" it would be a bug, as far as I can tell...

> would be conforming! Some will ignore the attribute and have the parent's 
> value inherit down as if the attribute wasn't there, others will not 
> ignore the attribute and will thus have the value not be inherited...
> 
> If you consider this "defining how to handle unknown values", then we have 
> very different ideas of what is meant by "define".
> ...

Indeed.

The outcome of this definition in any case is that no new values for 
xml:space can be introduced -- whether that was the intention, I don't know.

BR, Julian
Received on Tuesday, 30 December 2008 10:23:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:09 GMT