Re: Polyglot Markup Formal Objection Rationale

Jirka Kosek writes:

> On 5.11.2012 15:04, Smylers wrote:
> 
> > 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.
> 
> Yep, definition of polyglot markup should be definitively normative.
> 
> > * 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?
> 
> Honestly, I don't care much about this.

Thanks, Jirka.

Would anybody else object to the description parts of the Polyglot spec
not being normative (so long as the definition is)?

> > > 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.
> 
> WG has limited resources and there are more urgent issues.

Currently this spec has a Formal Objection against it, which means that
resources need to be spent on dealing with it somehow. If a change can
be found which would remove the Formal Objection (and not create another
one) that might be the least work in total.

> > > 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. 
> 
> Well, actually your logic would allow either UTF-8 or UTF-16 encodings

Not "my" logic, but the outcome of the definition of polyglot HTML being
mark-up that can be processed with identical meanings as both text/html and
XHTML.

> But in usual standards meaning profile is clearly defined subset and
> such subset can define additional requirements like allowing only
> UTF-8 in order to make interop easier.

The Polyglot spec doesn't claim to be a profile; the word "profile" does
not appear anywhere in it.

> > 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).
> 
> No, Polyglot has to explicitly define that only allowed encoding is
> UTF-8 because we want polyglot to use only UTF-8

Who's the "we" that wants that?

Having additional restrictions like this doesn't match the Polyglot
spec's own definition of "polyglot markup". Either the additional
restriction is a bug, or the thing the spec is defining isn't simply the
common ground between text/html and XHTML -- in which case the spec's
introduction (and possibly also its title and rationale) needs amending.

If there are to be additional restrictions then yes, indeed they have to
be normative. I'd also suggest they need to be clearly distinguished
from the requirements that are implied by being the intersection of XML
and text/html, so that it is clear to anybody reading the spec that
these are additional things they need to do.

That's another reason to not have the 'implied' requirements claim to be
normative: they obscure that there are actual normative requirements in
there which need to be followed.

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 Tuesday, 6 November 2012 10:53:20 UTC