- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 16 Feb 2010 00:31:41 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
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