Re: An HTML language specification

Philip TAYLOR wrote:
> In a sense, what you are doing is adding one level of complexity;
> it is quite possible that there could be other levels of complexity,
> but surely the starting point must be the definition of HTML 5 as
> a static language (as a "serialisation", if you want to use the
> current jargon).  And that is what Mike's document sets out to do.

Philip, the problem is that defining parsing of that serialization has 
to either allow for complexity to be added on top, or we have to have 
one parsing spec that says to do X and another one that says "but 
actually, ignore this other spec, and do Y in that circumstance instead".

It's doable; the question is whether the cost in terms of complexity of 
the integration points and potential skew between specs (the latter is a 
problem no matter which of the two approaches is taken) is worth it.

> What is not clear to me (and I know, to others too, though the
> lack of clarity is by no means universal) is why anyone should
> seek to conflate these three distinct phases, when the benefits
> of keeping them distinct seem so clear.

The benefit of "conflating" is that it's actually easier (simpler to 
write, simpler to read, _much_ simpler to verify correctness) to specify 
parsing unambiguously that way.

-Boris

Received on Thursday, 20 November 2008 16:36:40 UTC