W3C home > Mailing lists > Public > public-html@w3.org > November 2012

Re: Polyglot Markup Formal Objection Rationale

From: Jirka Kosek <jirka@kosek.cz>
Date: Sun, 04 Nov 2012 20:59:09 +0100
Message-ID: <5096C90D.3010802@kosek.cz>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: "public-html@w3.org" <public-html@w3.org>
On 4.11.2012 15:59, Lachlan Hunt wrote:

> 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.

Polyglot is nothing more then just profile of HTML5 which defines subset
of syntax. There is no reason why definition of such profile shouldn't
be normative. If you for some reason decide to conform to such profile,
it's much better if such profile is normatively defined.

> 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.

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. But as Polyglot is subset of HTML5 this is quite
unlikely, and if there is such mismatch present I hope that
corresponding bug is filled.

> 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.

W3C publishes on REC track many specifications. It's you free will to
choose to which to conform to. Having Polyglot as a REC doesn't mean
that W3C prefers such serialization subset of HTML5 over full HTML5 or
XHTML5 syntaxes. It just say that if you want to produce HTML5 content
which can be processed by XML tools at the same time you should do it in
this particular way.

> 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.

Personally, I don't care whether Polyglot will be on REC track or
whether it will be "just" Note. I just wanted to summarize why I think
that your reasoning for having just non-normative note is wrong.

And although I can be considered as very XML-biased I don't consider
Polyglot as a preferred syntax for general case. I would recommend it
only for very special scenarios. If you need to process HTML5 as XML it
is easier not to put additional burden on content producers and use
library like http://about.validator.nu/htmlparser/ to turn HTML into XML.

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------


Received on Sunday, 4 November 2012 19:59:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:35 UTC