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

Ian Hickson wrote:

> There are many ways to define error handling; they each have different 
> advantages and disadvantages. My point on this thread was not to support 
> one over another. I am only saying that specs need to define all behavior 
> that is relevant for interoperability, including error handling. Merely 
> defining valid behavior and leaving all other behavior undefined is not 
> enough -- it leads to lack of interoperability, such as the many 
> differences between Web browsers, Web servers, and other tools today.

Defining error handling is a subset of defining behavior. I'm not 
convinced that defining behavior is always a good idea. I definitely 
believe that defining syntax, semantics, and behavior in one spec is a 
very bad idea.

> Note also that I'm not trying to single out error handling here. It is the 
> processing requirements that need to be defined in detail. To use XML as 
> an example -- XML doesn't actually define how to parse XML, and thus there 
> is no concept of the processing of an end tag, which then makes it very 
> hard to define things such as document.write(), SVGLoad events, <script> 
> processing, etc, in languages that use XML. 

That's a feature, not a bug. Different systems will have different needs 
for processing. The weakness of the XML spec is that it actually does 
define a little more processing than it needs to or should. It would be 
a stronger spec had it limited itself to the definition of what a 
well-formed document is.

> It also doesn't define the 
> error handling for incorrect values on the xml:space attribute.

Yes, that's a bit of a weird corner case. Applications are free to treat 
that as an error or not as they see fit. However that's reasonable given 
that most applications don't really care about xml:space at all.

>> For instance, for XML, sending non-ASCII characters when the declared 
>> encoding is US-ASCII is a fatal error, and I definitively want to stay 
>> it that way.
> 
> XML does a much better job than most specs at this, but it still leaves a 
> lot undefined, e.g. the cases given above, or whether errors in XML 
> resources in applications that are processing the results incrementally 
> should cause earlier output to be replaced by an error message or whether 
> the results can continue to be shown and can continue to be interactive 
> [1], or how error messages should be represented in higher-level 
> structures such as the Infoset or the DOM.

Again, feature, not a bug. The designers of XML wisely recognized that 
no one approach would satisfy all use cases. Thus some applications can 
use a streaming event model that gives up on the first error but retains 
previously processed data, while others can simply fail the entire 
document if an error is detected. And other approaches are possible as 
well.

XML's domain is far broader and longer lasting than the limited browser 
domain HTML 5 is aiming at. Nonetheless, I think the XML family of 
specifications has a style that could very profitably be imitated in 
HTML 5. Attempting to define syntax, behavior, parsing, display, user 
interaction, error handling, semantics, object model, and more in one 
spec is doomed to failure. It is a massive, waterfall model of spec 
design; and in the end it's just not going to work.

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Received on Tuesday, 30 December 2008 16:44:04 UTC