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

Maciej Stachowiak wrote:
> 
> 
> 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.

I should clarify my previous posting [1]. That too was meant as a formal 
objection from me to posting as a WD. (And yes, that does mean that I 
disagree with Hixie).

/ Jonas

[1] http://lists.w3.org/Archives/Public/public-html/2009Jan/0317.html

Received on Tuesday, 27 January 2009 00:25:40 UTC