[whatwg] Content Model Restrictions on table>tr in HTML

[Bjoern Hoehrmann]

* Ian Hickson wrote:
>I agree that the requirements could be deduced. But unless they are 
>actually there, they aren't actually there. If you see what I mean.

If something can be deduced it "is there" for all intents and purposes.
You can look at this from a very practical perspective: someone wants to
build a "HTML5" "conformance checker". He has already implemented an al-
gorithm that transforms a document into a tree and parse errors and an
algorithm that determines whether a document conforms to the draft. Now,
in order to complete the tool, he has to implement a third algorithm
that determines whether a document conforms to section 9.1 of the draft,
possibly by deducing which of the requirements in that section are al-
ready checked for by the algorithms he already has, which is an extremly
wasteful excercise.

You can also put it like this: a conformance checker implementer needs
to read only those parts of the draft that define document conformance
criteria. According to you, section 9.2 does not define any, therefore
he does not need to read it. This implies that there are no conformance
criteria for conformance checkers in section 9.2. Yet there are, the
checker must report at least one parse error if there is any. Why? The
draft has no explicit requirement that documents must be free of parse
errors. Maybe that can be deduced from section 9.1, but doing so is an-
other extremly wasteful excercise.

>> It is actually possible to construct a document that parses into a 
>> conforming tree without generating parse errors that does not conform 
>> to the requirements in section 9.1, odd as that may seem.
>
>Could you elaborate on this? I don't doubt that there are mistakes,
>but I am not aware of any.

A missing </option> implies non-conformance but no parse error per 9.1
and 9.2 respectively. None of these problems would exist if you had
simply defined something like

  A document conforms to this specification if and only if it can be
  parsed into a tree structure that conforms to this specification
  without error in accord with the applicable specifications.

Or ensured in some other way that no clause that implies the definition
of a constraint can be removed without changing what conforms to the
specification.

>What is your point? I'm confused. The syntax section is clear that you 
>can't create such a document. This is, in fact, one very important example 
>of why the syntax section is important -- if an authoring tool tried to 
>generate a document that had a <pre> inside a <p>, it would be 
>non-conforming, but only because of the syntax section (9.1.2.5:2), not 
>because of the parser section -- the parser section wouldn't be able to 
>determine there was an error.

There are no authoring tool requirements in that section and I do not
see how the tool would be non-conforming. Further, yes, the parser
section is sufficient to determine something is not right because it
allows us to determine the result of doc == parse(serialize( doc ))
independent of the serialize function. It is impossible for the tool
to succeed in generating such a document, no matter what 9.1.2.5 might
say.

The draft has "A p element must not contain blockquote, dl, menu, ol,
pre, table, or ul elements". It is not possible to tell whether or not
the requirement is being followed by a document that does not follow
the requirement.

  A conformance requirement must be testable. That is, you must be
  able to tell whether a product follows it or not. If you can't tell
  if a product follows it, then it isn't a conformance requirement,
  and shouldn't pretend to be one.

Without the parsing algorithm it is impossible to determine whether
a p element contains a pre element without assuming that p elements
never contain pre elements, and if you assume that, there is nothing
left to determine. The conformance requirement really only applies
to "conforming documents" but that is quite unclear from the draft.

  A conformance requirement must also be clear (either by context
  or explicitly) about exactly what kind of product it applies to.

That certain constructs cannot be represented using the HTML syntax
is important information that should be highlighted by the draft, but
9.1.2.5 is very far from doing an adequate job to that effect. And I
can't see what else it might be there for.
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/