Re: ISSUE-59: normative-language-reference FPWD

On Jan 23, 2009, at 5:30 AM, Sam Ruby wrote:

>
> James Graham wrote:
>> Sam Ruby wrote:
>>>
>>> In yesterday's call, a number of issues were raised when the topic  
>>> of making "HTML 5: The Markup Language" available First Public  
>>> Working Draft.  A number of issues were raised during the  
>>> discussion.  Whether these were merely issues to be worked or meet  
>>> the criteria for a Formal Objections was less clear to me.
>>>
>>> To help facilitate and focus the discussion, a few links:
>>>
>>> http://www.w3.org/html/wg/markup-spec/
>>> http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd
>>> http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews
>>> It surprises me to have to say this given the makeup of this  
>>> group, but: don't be shy!
>> The markup language spec duplicates material that is already in the  
>> HTML 5 spec. My understanding is that a FPWD puts a document on the  
>> REC track so I presume it would be expected to be a largely  
>> normative document. It is clearly a bad idea to duplicate normative  
>> material between two different documents. Therefore it seems that  
>> we should seriously consider whether putting this document on the  
>> REC track is the right thing to do; I guess doing so would require  
>> us to remove the corresponding material from HTML 5, get all the  
>> cross-references right do as not to leave any undesirable gaps  
>> where the two specs join and continue to edit the documents in  
>> lockstep so they do not become out of sync in the future. We would  
>> really want to be reasonably certain that this represented a net  
>> win for the utility of the whole before embarking on such a  
>> substantive change given the tight timeline before LC (either in  
>> the W3C's original estimation or in the editor's estimation).
>> My intuition is that this effort is not worthwhile and that the  
>> markup spec should remain as an informative document rather than as  
>> a normative one. I would fully support publishing such a document  
>> as an informative note along with the final HTML 5 spec.
>
> I may be wrong, but I sense that there are a number of hidden  
> assumptions behind this concern:  (1) it is inevitable that both  
> documents will result in candidate recommendations, (2) that such  
> CR's will be published roughly concurrently, and (3) that the  
> current tight timeline[1] is achievable.
>
> I know I don't believe that all three are true.  I suspect many  
> others would be willing to say the same thing, though we may differ  
> on which ones we think are most likely.
>
> Personally, I believe that "HTML5: AVaAAfHaX" is largely the right  
> long term direction, though the rate of change and the presence of a  
> number of controversial items in that document makes it difficult to  
> make that statement with any precision.  It may very well be true  
> that "HTML5: aML" is all that we can obtain consensus around in the  
> form of a CR in 2010.  Another significant chunk could become a CR  
> in 2012/2013, and perhaps the remainder two to three years after that.
>
> But my crystal ball is no better than everybody else's.  My only  
> point is that active precluding any possibilities at this point  
> might turnout to be an rather unfortunate premature optimization  
> long term.
>
> At the moment, it appears that what is in "HTML: aML" is intended to  
> be a proper subset of what is in "HTML5: AVaAAfHaX", and this effort  
> has already produced results in the form of validator.nu becoming  
> more consistent with "HTML5: AVaAAfHaX".

I would definitely be opposed to taking a subset that excludes APIs  
and parsing requirements to CR before the full spec. That seems like a  
guarantee of trouble, since changes to various features very often  
affect both the scriptless-authoring-only subset and the full  
language, so having this particular subset of the spec further along  
the REC track will make it harder to fix problems found during the CR  
period of the HTML5 spec proper. It is almost certain that many  
problems, including quite severe ones, will be found during the CR  
period. Certainly this has been my experience with other Web standards  
documents, as an implementor. Indeed, a rush to PR has led to many  
documents reaching REC status while still containing severe flaws, at  
which point it is generally considered that the document "can't" be  
fixed, because you can't make major changes to a REC, so the only  
option would be to rescind the REC, which no one ever wants to do.  
Taking a spec without implementation conformance requirements to CR  
subverts a large part of the purpose of CR, which is to demonstrate  
the feasibility of interoperable implementations.

Even if the documents are edited in lockstep, there is a high risk of  
contradiction if they spec the same things. It creates needless  
process headache, and the only benefit seems to be to a small group of  
technical experts who are able to understand a technical specification  
but find scripting and implementation requirements distasteful.

I think these risks are too great to take, therefore I oppose placing  
a subset spec separately on the REC track, and yes, this objection  
rises to the level of a Formal Objection.

I am not opposed to having an informative document about the language  
syntax. I think we should decide whether this document is going on the  
REC track before publishing a WD.

Regards,
Maciej

Received on Monday, 26 January 2009 23:59:29 UTC