- From: Larry Masinter <masinter@adobe.com>
- Date: Mon, 3 Dec 2012 08:17:34 -0800
- To: Noah Mendelsohn <nrm@arcanedomain.com>, Henri Sivonen <hsivonen@iki.fi>
- CC: "www-tag@w3.org List" <www-tag@w3.org>, Norm Walsh <ndw@nwalsh.com>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
There were several justifications given in the argument against moving the polyglot markup document to Rec that I thought were worth discussing. Please look at the HTML working group bugzilla bug report and mailing list for background. =========== "Sufficient review" It may be appropriate to question a document's progression on the grounds that it has not had sufficient review by the affected community. However, in the case of the polyglot specification, I think there is sufficient evidence that those who care about producing and consuming polyglot documents have reviewed this specification. Evidence of "insufficient review" might consist of examples of areas where a specification has obvious blatent errors throughout. =============== "Working group, community interest or lack thereof" > The Recommendation track implies a level of endorsement from the group > that I do not believe is warranted in the case of these guidelines. The fact that there are others in the community (or working group) who do not care about the usage of the technology in the draft isn’t a determination to the decision of whether a draft is "normative". Some people are not interested in high quality graphics, some are not interested in accessibility, some are not interested in internationalization, even if all of those are addressed. ================= "Why a spec is 'normative'" A "normative" technical specification is one that can be specified in a contract, e.g., "Our system produces valid polyglot specifications". This is much more than a convenience for authors. It's also a technical specification that can be followed by software developers who wish to produce polyglot documents. Without it, you would have to infer technical advice which is only implicit in the HTML spec. ================== Possibility of conflict Having the possibility of two specifications which might need to be kept in sync and for which ambiguity might arise might be inconsistent with each other. But the risk of inconsistency is no greater than the risk of inconsistency in the HTML5 spec itself, and in the "willful violations" of various other specifications. There are no examples given of such conflicts, or even previous conflicts which have been resolved during review. If conflicts area discovered, they can and should be addressed as errata. ============== "Perception" > 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. Recommendations are published by the entire consortium in the name of the entire implementing community. "perception of endorsement" is not acceptable criterion for objecting to progression of a draft. "Last Call" and "Recommendation" are technical review, not political or PR reviews. ========================= > 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. Recommendations come with a scope of applicability. It is legitimate to complain if a recommendation makes claims of a broader scope than it has been reviewed for, but the polyglot document is explicit about its scope and appropriate. "IF you want to produce a polyglot document, here is how you do it". (I might object to the HTML5 specification claiming it is appropriate for email, for example, as I don't think any HTML-email producers or consumers have reviewed the HTML5 spec for applicability). ========================= "Intention for continuing to work" Paul Cotton's suggests a distinction between Recommendation and Note be based on the working group intention to continue work on a specification. But there are many Recommendations for which, once done, the working group has disbanded. Recommendations are recommendations of the entire community, and the makeup and organization of working groups in the W3C depends on many non-technical issues. The determination of Recommendation or Note should be determined on merit and whether there is sufficient interest to meet the requirements for W3C Recommendation. And this specification, I believe, has a much larger constituency of interested parties than most W3C recommendations.
Received on Monday, 3 December 2012 16:19:29 UTC