This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Raising this against HTML5 spec for now as recommended by Sam Ruby (http://lists.w3.org/Archives/Public/public-html/2010Feb/0411.html). The Status sections for RDFa-in-HTML and Microdata should be clear about the status in the WG, and their relation with respect to the HTML5 spec. I propose to use something similar to what the RDFa editor's draft has: "The publication of this document by the W3C as a W3C Working Draft does not imply endorsement by the W3C HTML Working Group or the W3C as a whole. In particular, * There are one or more alternate methods of adding data without using RDFa, such as [microdata]. * There are discussions of alternate extensibility mechanisms, covered in [issue-41], which might allow other ways of integrating RDFa. * There is concern that continued development of this document belongs in a different working group." That being said, other wording would be ok as well, as long as it's consistent in both specs.
Julian - you are aware that status sections are purview of the W3C staff, not the work groups or the editors, right? http://www.w3.org/2005/10/Process-20051014/process.html#DocumentStatus 7.8.1 Document Status Section points to: http://www.w3.org/2005/07/pubrules?uimode=filter&uri= * There MUST be a status section that follows the abstract, labeled with an h2 element with content "Status of This Document". The Team maintains the status section of a document. - - - It is my (personal, opinion, not necessarily shared by my co-chairs) that it would be best if Status sections not be used for posturing or positioning, and it is particularly inappropriate for extended discussion on issues that have not been raised within the group. As such is it my (non-binding) recommendation that all documents go forward with the same status sections that have always been used by this working group, i.e., it is my recommendation that the changes that were recently made to status section in the RDFa in HTML draft be reverted. I will also note that Ian has been including simple issue markers with links but with no additional commentary other than "blocks progress to Last Call" in the documents he is editing, and has indicated a willingness to continue to do so. Furthermore, Manu has indicated that he is willing to follow Ian's lead here. http://lists.w3.org/Archives/Public/public-html/2010Feb/0416.html http://lists.w3.org/Archives/Public/public-html/2010Feb/0430.html
The status section already says: "The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C HTML working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section." ...so I don't understand the request. What exactly is the problem?
(In reply to comment #0) > Raising this against HTML5 spec for now as recommended by Sam Ruby > (http://lists.w3.org/Archives/Public/public-html/2010Feb/0411.html). > > The Status sections for RDFa-in-HTML and Microdata should be clear about the > status in the WG, and their relation with respect to the HTML5 spec. > > I propose to use something similar to what the RDFa editor's draft has: > > "The publication of this document by the W3C as a W3C Working Draft does not > imply endorsement by the W3C HTML Working Group or the W3C as a whole. In > particular, > > * There are one or more alternate methods of adding data without using > RDFa, such as [microdata]. > * There are discussions of alternate extensibility mechanisms, covered in > [issue-41], which might allow other ways of integrating RDFa. > * There is concern that continued development of this document belongs in a > different working group." > > That being said, other wording would be ok as well, as long as it's consistent > in both specs. > I think the only aspect of this which is not already included in the draft is the list of three specific issues. Out of those three issues, the second one is already tracked, as ISSUE-41. The other two do not have bug reports or issues. If they are reported to the group, then we can add status markers automatically, and then remove them once the issues are resolved. The specific two items I am talking about are: * 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. Can you please file bugs reflecting those issues? I would not consider this bug report a valid report of those two issues because (a) it lists more than one issue and (b) it does not actually request resolution of those two issues, it requests a change to the status section. I do not see how a change to the status section would resolve the underlying issues. I also recommend including the information listed here when filing bugs on those two additional issues: http://dev.w3.org/html5/decision-policy/decision-policy.html#bugzilla-bug * A clear statement of a problem with the specbug reports are more useful if they identify concrete problems. * Only one issueplease use separate bugs for separate issues. * An indication of what section or sections of the spec are affected. * At least one suggested way to solve the problem. Optionally, this can include sample spec text. Listing multiple alternatives is ok, and even a vague suggestion is fine at this stage.
Julian, given that this bug is worded as 'Consistent "Status" sections', is the following sufficient to close this bug? http://lists.w3.org/Archives/Public/public-html/2010Feb/0463.html
(In reply to comment #1) > Julian - you are aware that status sections are purview of the W3C staff, not > the work groups or the editors, right? > ... Yes, that's why I didn't want to raise a bug over here in the first place. But I was told by the chairs to do it anyway.
(In reply to comment #4) > Julian, given that this bug is worded as 'Consistent "Status" sections', is the > following sufficient to close this bug? > > http://lists.w3.org/Archives/Public/public-html/2010Feb/0463.html How does this make the "Status Of This Document" sections consistent? I'm happy with introducing the same mechanism to link to tracker issues everywhere, but it seems to be a complete orthogonal discussion to me.
Sam has asked me to comment on this bug. We're in a catch-22 here: First, Larry and Julian wanted the SotD sections to reflect the issues concerning Microdata, HTML+RDFa and Canvas 2D. It was a reasonable request, so I made it. Then I found out that the SotD sections are off-limits to editors. Maciej had logged a number of bugs related to the HTML+RDFa draft. It was both more transparent to the reader, and easier for me to understand the state of the draft by inserting those bugs in line with each section. Also, in the name of compromise, I added Larry and Julian's issues to the bug list so they would be interested in the document to notify the W3C team to keep the bugs in mind when re-writing the SotD section. The only issue that relates to HTML+RDFa is ISSUE-41, and it doesn't really apply to any particular section, but the concept that HTML+RDFa may one day be specified in a different way in order to be integrated with HTML5. I put a temporary placeholder bug to point to ISSUE-41 while some of the source code was figured out for integrating issues into the HTML+RDFa draft. Now I'm being asked to remove all of the bugs from the status sections in the HTML+RDFa draft and make the SotD section match the HTML5 draft. This makes the current status of the HTML+RDFa draft much more difficult to grok for reviewers... it is less transparent as a result. In addition, we're completely ignoring Julian and Larry's input for the SotD section in the current draft, which may result in objections to publish the draft. That said, I'll do what the chairs are asking (even though I think it harms the readability and transparency of the specification): 1. Revert the SotD section to what was there over a month ago. 2. Remove all bugs reported in the status sections of the HTML+RDFa spec. 3. Modify the wording of one of the bugs and insert ISSUE-41 as a blocking item for HTML+RDFa LC.
Julian, Can we close this? Or is there still something we need to resolve on this?
Created attachment 827 [details] diffs between the status sections
Yes, I believe this can be fixed. BTW: see http://www.w3.org/Bugs/Public/attachment.cgi?id=827 -- it might be good to check that spec-specific stuff and generic stuff always comes in the same order in order to simplify comparison.
(In reply to comment #10) > BTW: see http://www.w3.org/Bugs/Public/attachment.cgi?id=827 -- it might be > good to check that spec-specific stuff and generic stuff always comes in the > same order in order to simplify comparison. I will personally check on that next time we publish. Hixie, Manu, In the mean time, if you guys could try to arrange the parts of status sections in your current Editor's Drafts so that the info comes in the same order, that would be great.
(In reply to comment #10) > Yes, I believe this can be fixed. OK, per that comment, and noting that the SOTDs for both docs are roughly in alignment now (though they could be tweaked a bit further to bring them closer -- see previous comment), moving this to resolved=fixed.