Re: Polyglot Markup Formal Objection Rationale

I disagree with the views of Lachlan, Henri and Glenn. Polyglot Markup 
should be on the recommendation track as it would benefit authors if PM 
gained recognition as a format - and thus an identity - of its own. See 
below.

Lachlan Hunt, Sun, 04 Nov 2012 15:59:50 +0100:

> 1. Normative vs. Non-Normative
> 
> Specifications should be considered normative when they seek to 
> define implementation and authoring conformance criteria.

PM does define authoring conformance requirements.

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

PM defines - it does not just describe - an authoring practise that is 
not defined or described whether in XML or in HTML5. For instance, 
HTML5 says that a DTD/DOCTYPE is not needed for XML. While the HTML 
doctype *is* needed in PM. And HTML5 - and XML - say that one should 
use the XML declaration - which one, for HTML5-authoring conformance 
reasons, should not use in PM.

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

HTML5 says: "In XHTML, the XML encoding declaration should be used for 
inline character encoding information, if necessary." But HTML5 does 
not say that the XML encoding declaration isn't necessary for polyglot 
mark-up served as XML. Yes, one can find out, from XML, that according 
to XML’s criteria, then polyglot markup - which is limited to UTF-8 - 
does not need the XML encoding declaration. But whether XML and HTML5 
has the same understanding of "necessary", is unknown … (E.g. HTML5 
does not forbid you from using the XML encoding declaration just 
because the "need" arrissed from a bad XML authoring tool that failed 
to default to UTF-8 - whereas Polyglot Markup forbids you, even in that 
case, from using the XML encoding declaration.)

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

What are "authors"? For WYSIWYG tools, it would have been quite 
practical if they used the polyglot markup format. It would give 
WYSIWYG editors the following features:

 * New documents would NOT ONLY DEFAULT to UTF-8 - they would
   BE LIMITED to use UTF-8.
 * Document "wizards" did not need ask authors to pick format
   and encoding.
 * The problem that your WYSIWYG editor distorts the preferred
   syntax/serialization would become more seldom.

And other benefits.

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

* The polyglot markup specification contains numerous links. It tries 
to document every claim that it makes. And if there is something it 
doesn't have a pointer for, then a pointer could be added. If PM would 
be taken in pointing to an outdated specification, then that would be 
enough to devaluate its value, regardless of its recommendation status.
* HTML5 - and even WHATWG HTML - is becoming more and more 
"distributed". The latest example is probably the Encoding 
specification. There is no fundamental difference between the way 
Polyglot Markup points to XML and HTML5, and the way HTML5 itself 
points to other specs.
* Where are the "duplication of normative definitions"? As told above, 
Polyglot Markup draws conclusions that are not drawn elsewhere. 

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

Not a problem.

> However, support among the working group members for producing or 
> recommending the production of polyglot documents is far from 
> universal.

Is it not? Where is the opposition? And what is it based on? Everything 
in PM is in conformance with HTML5 - as you have yourself pointed out.

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

This sounds like FUD to mine ears … Polyglot Markup itself describes 
the PM format as an option: "All web content need not be authored in 
polyglot markup." Etc. (Feel free to suggest an even weaker statement …)

I would also remind you that Appendix C (et al) was not normative, but 
still affected authoring practise a lot. So not being normative is not 
a guarantee against possible bad effects. Perhaps it is the opposite. 
Perhaps Appendix C harmed because it was not taken seriously enough (by 
the specification community).
-- 
leif halvard silli

Received on Sunday, 4 November 2012 18:41:34 UTC