Fwd: Polyglot Markup Formal Objection Rationale

---------- Forwarded message ----------
From: Glenn Adams <glenn@skynav.com>
Date: Mon, Nov 5, 2012 at 8:58 AM
Subject: Re: Polyglot Markup Formal Objection Rationale
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>

To a certain extent, using the terms "normative" and "non-normative" with
regard to publishing W3C documents is a mis-nomer. The W3C does not label
documents as normative or non-normative. It labels them as REC or NOTE.
What determines if such a document is normative or not is not related to
what the document calls itself, it relates to how other specifications
(whether published by W3C or not) refer to it. A NOTE can be referenced as
a normative document and a REC can be referenced as a non-normative
document.

So I suggest you de-focus on the notion of normativity, and instead simply
focus on the advantages or disadvantages of using either REC or NOTE
approach.

On Sun, Nov 4, 2012 at 3:59 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au>wrote:

> At the HTML F2F, I was asked to provide rationale for my previously filed
> formal objection to the Polyglot Markup specification.
>
> http://dev.w3.org/html5/**status/formal-objection-**status.html<http://dev.w3.org/html5/status/formal-objection-status.html>
> http://lists.w3.org/Archives/**Public/www-archive/2011May/**0050.html<http://lists.w3.org/Archives/Public/www-archive/2011May/0050.html>
>
> This rationale includes:
>
> 1. Why the html-polyglot authoring guidelines should be produced as a
>    *non-normative* document, and
> 2. Why it *should not* be published on the recommendation track.
>
> 1. Normative vs. Non-Normative
>
> Specifications should be considered normative when they seek to define
> implementation and authoring conformance criteria.  Documents that merely
> seek to describe authoring practices or provide tailored information to a
> particular audience about content which is normatively defined elsewhere,
> should be non-normative.
>
> The HTML5 specification already normatively defines the conformance
> criteria for all of the features employed in both serialisations.  The
> necessary requirements to meet in order to produce a polyglot document are
> inherently logical conclusions from these criteria.
>
> The polyglot guidelines only serves to document the overlap of the two
> serialisations as a convenience for authors who wish to pursue this style
> of document production, and should not try to normatively define that which
> is already normatively defined in HTML5.
>
> Such duplication of normative definitions has the potential for
> introducing unintentional conflict between the two specifications.  By
> ensuring that the polyglot guidelines remain non-normative, then it is
> clear that, even in the case of such a conflict, the HTML5 specification's
> normative requirements take precedence over the guidelines' non-normative
> descriptions.
>
> 2. Recommendation Track vs. Note Track
>
> The Recommendation track implies a level of endorsement from the group
> that I do not believe is warranted in the case of these guidelines. Note
> that the boiler-plate Status section of a W3C Recommendation clearly states:
>
>   "This document has been reviewed by W3C Members, by software
>    developers, and by other W3C groups and interested parties, and is
>    endorsed by the Director as a W3C Recommendation."
>    -- Pubrules (W3C)
>
> Publication as a recommendation could lead to the perception by the
> greater web community that the HTML WG itself endorses and recommends the
> adoption of these authoring practices by web developers.
>
> However, support among the working group members for producing or
> recommending the production of polyglot documents is far from universal.
>  It is therefore not in the interests of the working group to either
> discourage, nor endorse through the recommendation track, the authoring of
> polyglot documents.
>
> Publication as a note, instead, allows authors to obtain information about
> producing polyglot documents if they choose, without implying any such
> endorsement, nor discouragement, from the working group itself.
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
>