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

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 30 Dec 2008 11:24:52 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <Pine.LNX.4.62.0812301115560.12643@hixie.dreamhostps.com>

On Tue, 30 Dec 2008, Julian Reschke wrote:
> 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?

What you describe isn't a fix, it's a statement of intent. It makes no 
sense really for a specification to say what future working groups will 
do, because we don't know.

Furthermore, not ever introducing new void elements is hardly a fix to the 
problem of not being able to introduce new void elements!

In any case, in this particular case the problem isn't unsurmountable. 
Introducing new void elements is painful, but it's not impossible. Indeed 
HTML5 introduces several new void elements.

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

Why? What requirements would it violate? The XML spec doesn't seem to 
constrain applications from doing whatever they want with the values they 
are passed, including the values of xml:space.

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

The outcome is exactly the outcome I described for the case where there is 
no definition, which makes sense since there is indeed no defintion here. 
It's just one more example of why specs should define processing 
requirements in detail, for all inputs, for all conformance classes.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 30 December 2008 11:25:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:59 UTC