- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 4 Nov 2012 19:41:04 +0100
- To: public-html@w3.org
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Henri Sivonen <hsivonen@iki.fi>, Glenn Adams <glenn@skynav.com>
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