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

Ian Hickson wrote:
> ...
>> 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.

Of course it makes sense for a specification to state how extensibility 
works.

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

The problem is *not* the inability to introduce them. The problem is the 
inability of producers and consumers which syntax to use for unknown 
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.

Yes, and that is a problem. It shouldn't be doing that, and it also 
should state once for all that new void elements can not be added anymore.

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

OK, so what exactly do you understand by "correcting"?

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

At this point I'm not sure whether we're disagreeing or not.

If the intent was to allow future extensibility for xml:space, this was 
a failure. On the other hand, if the intent was to allow exactly those 
two values, then the spec is fine the way it is.

So, assuming we *did* want extensibility here -- how would *you* define it?

Best regards, Julian

Received on Tuesday, 30 December 2008 11:42:59 UTC