IRI working group approved by IETF, call for volunteers for co-chair with W3C/IETF experience

With respect to ISSUE-56 and ACTION-172 there is some news
that the IRI Working Group has been approved, with mailing list
 public-iri@w3.org<mailto:public-iri@w3.org>

See http://lists.w3.org/Archives/Public/public-iri/2010Jan/0021.html
and NOTE WELL
   http://lists.w3.org/Archives/Public/public-iri/2010Jan/0022.html

for the announcement.

The HTML change proposal to ISSUE-56 is to change HTML to make  a normative reference to the document which is under discussion in this group; of course, it's important to keep the two in sync.

I'm not sure the current Working Group Decision Policy is adequate for maintaining coordination, since I'm being asked to provide specific wording in the HTML document to reference something that itself should be subject to change and feedback from this group.

However, I will still update the change proposal. What I'm planning to do is to rebut the Comment #6 from Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207#c6

Briefly (although developing this argument will take a little more time to develop), I intend to argue that the reason for rejection is inadequate. The text supplied is not "woefully vague", it is sufficiently precise to insure interoperability of implementations, and that while Hixie may be "looking for something which is unambiguous, absolutely clear, precise, and explicit", the text supplied in the change proposal is, in fact, completely sufficient to insure interoperable implementations, and I challenge anyone to come up with any reasonable interpretations of that text supplied that would result in implementations that were not, in fact, interoperable.

And the idea that a language specification and technical standard should "ideally" have "a set of steps introduced with a MUST requirement, which can be blindly implemented with little thought, with no interpretation needed" is itself counter-productive; the areas where the HTML specification does so are harmful, produce normative requirements which are harmfully over-restrictive as to implementation technique or wind up over-specifying requirements in ways that are ultimately anti-competitive.   As a reference implementation or a sample of how a set of constraints CAN be implemented, a set of instructions about how to accomplish the interoperability requirements are sometimes useful, but in most cases making the sample algorithm into MUST normative requirements actually helps no-one in the long run, in general, or specifically in this case.

Larry
--
http://larry.masinter.net