Re: Polyglot Markup Formal Objection Rationale

Jirka Kosek writes:

> On 5.11.2012 13:37, Smylers wrote:
> 
> > > If you for some reason decide to conform to such profile, it's
> > > much better if such profile is normatively defined.
> > 
> > Yes. Jirka, would a normative definition like that satisfy you?
> 
> I don't understand to which definition you are now reffering to.

My apologies: I re-ordered my message and failed to spot that dangling
"that".

It was supposed to refer to:

> > Surely the definition of polygot mark-up is simply a statement
> > saying something along the lines of[*1] a document is conforming
> > polyglot if it conforms to both the XML and text/html requirements
> > of HTML5 and has the same meaning in both serializations -- that is,
> > it's a definition of the principle, by reference.
> > 
> > All the details and implications of what that means are simply
> > applying the normative requirements of the HTML spec, so they aren't
> > themselves defining anything.

    [*1] I'm sure the actual definition is more nuanced and would
    require more precision. I'm not suggesting my sentence above should
    be the definition.

That is:

* The definition of the term "polyglot markup" being normative (it
  currently isn't) and itself refer to normative definitions in the HTML
  spec.

* The consequences of that definition, the description of what it means,
  not being normative (they currently claim to be).

Would you be satisfied with that, or do you want the description parts
to be normative as well?

> I don't have strong position on whether Polyglot should be REC or
> Note,

Me neither -- hence why my message made no mention of that, and was
entirely on the matter of whether its contents are normative, on which
you did express a view.

> > > Well this problem (if ever exists) can be easily solved by adding
> > > one sentence to Polyglot which will say that in the case of
> > > conflicts HTML5 has precedence.
> > 
> > Yes. In which case, the Polyglot spec by its own admission would no
> > longer be canonical for those definitions and requirements. So it would
> > be bizarre, and confusing, for it to be simultaneously claiming its
> > requirements are normative and that it is out-ranked by the HTML spec.
> > In effect, that would make its descriptions non-normative. So it would
> > be less confusing, and more accurate, not to claim to be normative for
> > those parts.
> 
> Choosing those parts

It would be everything except for the definition of the term "polyglot
markup" (or "polyglot HTML", or "polyglot document")

> is probably more work then to add one sentence which can say that in
> the case of *potential* conflict HTML5 wins.

I don't think picking the (probable) least work for for spec writers is
a good way of deciding what a spec should say.

> For example as both in HTML5 and in XML you have some variety in
> choosing encoding, Polyglot must *normatively* define that only
> allowed encoding is UTF-8.

It can do that by reference; it doesn't need to so it explicitly.
Clearly by the definition polyglot HTML (being the overlap of text/html
and XHTML) a conforming polyglot document needs to use an encoding
which:

* Is allowed in conforming text/html.
* Is allowed in conforming XHTML.
* Can be declared in a way which is conforming in both representations,
  and has the same meaning in both.

If the only encoding that turns out to meets those requirements is UTF-8
then it necessarily follows that polyglot HTML documents must use UTF-8.
Saying "Polyglot HTML documents use UTF-8" is therefore a description of
a fact, and not itself a requirement; it places no further restrictions
on those already made by the simple definition of what polyglot HTML is.

If, on the other hand, it turns out there is some other encoding which
also meets the above criteria then that would be an example of a
contradiction between polyglot HTML being a simple profile of the
overlap between text/html and XHTML and it having its own normative
requirements. With a "precedence" sentence such as the one you suggest
above, this would mean that the definitions in the HTML spec take
precedence, so the 'requirement' in the polyglot spec has no meaning.

So I'd say the precise opposite: the polyglot spec needs _not_ to
explicitly define what the allowed encoding is, because it's either
redundant (requiring something which is already required anyway) or
wrong (contradicting the HTML spec, and therefore to be ignored).

Of course it's _useful_ for the polyglot spec to spell out that the
consequences of being simultaneously valid text/html and XHTML requires
using a certain encoding. But that isn't the same as being the normative
definition of it.

Cheers

Smylers
-- 
New series of TV puzzle show 'Only Connect' (some questions by me)
Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect

Received on Monday, 5 November 2012 14:04:58 UTC