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

Ian Hickson wrote:
> ...
> Application statements don't limit innovation. In fact, having detailed 
> specifications that define the precise rules for parsing and that give 
> precise rules for the processing models and so forth dramatically increase 
> the ease with which the respective protocols can be extended, because 
> there is no guesswork about exactly how various implementations are going 
> to handle the new syntax.
> ...

They can help with extensibility; but they can also ruin it.

For instance, if a specification requires recipients to accept *any* 
kind of broken input (by specifying how to parse it anyway), it 
essentially takes away all future extensibility with respect to syntax.

> For instance, adding a new property or new syntax to CSS is easy, because 
> CSS defines forward-compatible parsing rules, so there is no ambiguity 
> about how a down-level browser is going to process new features. However, 
> adding a new element to HTML is incredibly difficult, because every 
> browser differs in how it handles unknown syntax, because the specs never 
> covered this case.

But HTML5 to some degree has the same problem: as the set of void 
elements is hard-wired into the spec, no new void elements can be 
introduced. That by itself would be fine if it actually guaranteed that 
future versions of the language won't introduce new void elements, which 
it doesn't.

> Similarly, if we were to extend XML's xml:preserve attribute to have a 

xml:space?

> third value, we couldn't do so without checking how all the different XML 
> processors would handle the new value, because XML doesn't define how to 
> handle unknown values. ...

Yes, it does:

"The value "default" signals that applications' default white-space 
processing modes are acceptable for this element; the value "preserve" 
indicates the intent that applications preserve all the white space. 
This declared intent is considered to apply to all elements within the 
content of the element where it is specified, unless overridden with 
another instance of the xml:space attribute. This specification does not 
give meaning to any value of xml:space other than "default" and 
"preserve". It is an error for other values to be specified; the XML 
processor MAY report the error or MAY recover by ignoring the attribute 
specification or by reporting the (erroneous) value to the application. 
Applications may ignore or reject erroneous values." -- 
<http://www.w3.org/TR/xml/#sec-white-space>

So conforming processors either report an error or ignore the attribute; 
thus xml:space can't be extended *because* it defines error handling, 
not because it doesn't.

> ...

Best regards, Julian

Received on Tuesday, 30 December 2008 09:21:47 UTC