Trouble understanding a parable of specification, under the "ensure pre-insertion validity" list of steps

[amn]

Under point 6 of the list of steps to take to "ensure pre-insertion validity", as part of an attempt to implement a procedure involving the particular list of steps, I am having trouble unambiguously interpreting the following statement:

parent has an element child, child is a doctype, or child is non-null and a doctype is following child.

The test described by the statement is only effective if the node is an element, as evidenced by text prior to the quote above. However, I am unsure if the expression quoted above is equivalent to:

"*parent* has an element child _and_ (emphasis mine) *child* is a doctype, or *child* is non-null and a doctype is following *child*."

or if it is equivalent to:

"*parent* has an element child, _or_ (emphasis mine) *child* is a doctype, or *child* is non-null and a doctype is following *child*."

When implementing the procedure conforming to the list of steps, proper interpretation, as you might imagine, is absolutely critical.

I am asking whether the sentence should be re-worded to remove the kind of difficulty I am experiencing, if I am on to anything here. Alternatively, perhaps there is a "how to read the specification"-kind of document somewhere, which explains how to interpret these kind of linguistic statements? I consider myself well versed in English, but feel free to point out if this is a mistake I am making somewhere.

There may be other statements where this kind of ambiguity surfaces, the one quoted above was just an example, and happens to be the one I am practically involved with.

[annevk]

Thank you for raising this. It's equivalent to:

If one of the following is true:

• parent has an element child
• child is a doctype
• child is non-null and a doctype is following child

and I think it works due to our consistent usage of Oxford commas, but writing it as a list would be a lot clearer and we should do so.

[amn]

Thank you for thorough explanation. I have no issues with authors assuming an accepted convention such as Oxford commas. To that end, I think this issue can be closed, for my part at least. I will have to learn Oxford commas thoroughly and keep these in mind reading WHATWG documents in depth :)

Perhaps linking a "how to interpret the specification(s)"-kind of a document could be a thing to consider? It's hard for me to judge merits of such a thing -- the sentence in question may only be hard enough to interpret for a minority of people, like me. Or you could improve sentences in place, that sounds good too, although I'd imagine it'd be more effort.

[annevk]

On that front there's https://infra.spec.whatwg.org/ (and somewhat less helpful https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification), but neither of them go into this specifically.

At a higher level we have https://whatwg.org/style-guide, though that's more a guide for editors than for readers.

But we have rewritten phrases like this before to use lists so I think it's fair to keep this open.

[domenic]

In general I don't think Oxford commas fully solve the problems of making boolean logic clear to the reader. Even when programming, if I mix together && and || in a single expression I always put parenthesis around clauses appropriately. I think we should do the same here (with bulleted lists being a good prose counterpart).