Re: CfC: Publish HTML5, RDFa heartbeats and Microdata, 2D Context and H:TML as FPWDs

Maciej Stachowiak wrote:
> 
> On Feb 15, 2010, at 3:01 PM, Julian Reschke wrote:
> 
>> Maciej Stachowiak wrote:
>>> Which spec? The bug links all work for me.
>>
>> Now they do. It would have been great if it wasn't required to raise a 
>> bug to get something like this fixed. And also, if the editor would 
>> actually reply over here.
> 
> I assume the problem is just that bugzilla was down.

No the problem is that reporting issues on the mailing list is not 
sufficient to catch the editor's attention.

>>>> This is not fixed. Should I open a bug report?
>>> The actual situation is that HTML5, HTML Microdata, and HTML Canvas 
>>> 2D Context are using the same set of bug components right now. If you 
>>> have a better term to refer to that set of three specs, feel free to 
>>> suggest it, either by email or in the form of a bug. It would not be 
>>> accurate to
>>
>> I did. Here. The suggestion is not to say "HTML specifications", but 
>> simply "specification". Microdata is *not* an "HTML specification".
> 
> It's an extension to HTML5 with HTML in the title and if our CfC goes 
> through will be published by the HTML WG. But by that standard, 
> HTML+RDFa would also be an "HTML specification". So I agree the term is 
> not enlightening. Probably the least ambiguous thing to do is either 
> list the three specs covered, or split the bug lists somehow.

It's not only not enlightening, it restarts the discussion about what is 
"part of HTML5", and what isn't.

>>> say "These bugs, issues and e-mails apply to all specifications", 
>>> because it's not true that they apply to all specifications ever, all 
>>> W3C specifications, or even all specifications published by this 
>>> group. Just that set of three (currently).
>>
>> In which case I recommend that we create the products in Bugzilla now, 
>> so that the link can be accurate.
> 
> Some people have discouraged the idea of creating more components 
> because it would break people's existing tools. If others consider it 
> important for clarity, then we can create new components (or some other 
> distinguishing feature, such as keywords).

I think new components would be good, but keywords as workaround might 
work as well.

>>>> Raised as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9001>.
>>> Instead of filing a bug about wording of the status section, could 
>>> you please file bugs about the underlying issues? That is, what are 
>>> the problems that are identified by these two statements:
>>>   * There are one or more alternate methods of adding data without 
>>> using RDFa, such as [microdata].
>>>   * There is concern that continued development of this document 
>>> belongs in a different working group." which I think is very helpful 
>>> in understanding the status of these documents.
>>> ...
>>
>> What I requested (again and again) is that the Status sections be made 
>> consistent. See:
>>
>> "That being said, other wording would be ok as well, as long as it's 
>> consistent in both specs."
> 
> 
> What I'm hearing is that you are not specifically looking to address the 
> three issues listed in the HTML+RDFa status section, you just want the 
> two status sections to use the same wording. Please correct me if my 
> understanding is wrong.

No, that is correct.

> Would it satisfy your request if we removed the list of three issues 
> from the HTML+RDFa status section, and instead used the same status 
> wording that we have for all previous HTML WG Working Drafts? That 
> wording does not flag any specific issues, but it does have a general 
> disclaimer. It would be consistent across all our publications.

RDFa and Microdata are different in that there's clearly not consensus 
that they are in scope.

So

"* There is concern that continued development of this document belongs 
in a different working group"

appears to be a good annotation.

For 2dcanvas I recognize that we had that discussion two years ago 
(where I *did* say we should add that to the charter, but in the end we 
didn't).

> We would also continue the issue marker mechanism to allow any issue to 
> be flagged directly in our drafts, so long as it is reported to the 
> Working Group, and we're asking Ian and Manu to extend that mechanism to 
> our additional proposed drafts.

That's nice; I simply do not believe that we should use this mechanism 
for the Status sections; these should always be accurate.

Best regards, Julian

Received on Monday, 15 February 2010 23:32:29 UTC