- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 15 Feb 2010 15:18:30 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
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. > >>>> "These bugs, issues, and e-mails apply to all HTML >>>> specifications, not just this one." >>>> s/HTML specifications/specification/ >>>> unless we want to discuss what exactly an "HTML specification" >>>> is :-) >>> >>> 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. > >> 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). > >> ... >>> 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. 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. 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. Regards, Maciej
Received on Monday, 15 February 2010 23:19:05 UTC