9001 2010-02-15 11:34:16 +0000 Consistent "Status" sections for Microdata and RDFa 2010-10-04 14:57:32 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 julian.reschke mike ian mike mjs msporny public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 32092 0 julian.reschke 2010-02-15 11:34:16 +0000 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. 32096 1 rubys 2010-02-15 13:17:52 +0000 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 32102 2 ian 2010-02-15 19:27:50 +0000 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? 32105 3 mjs 2010-02-15 21:31:32 +0000 (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 spec—bug reports are more useful if they identify concrete problems. * Only one issue—please 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. 32113 4 rubys 2010-02-16 02:48:24 +0000 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 32156 5 julian.reschke 2010-02-16 08:42:01 +0000 (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. 32157 6 julian.reschke 2010-02-16 08:43:34 +0000 (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. 32346 7 msporny 2010-02-18 05:09:10 +0000 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. 32871 8 mike 2010-03-10 07:06:54 +0000 Julian, Can we close this? Or is there still something we need to resolve on this? 32875 9 827 julian.reschke 2010-03-10 09:40:51 +0000 Created attachment 827 diffs between the status sections 32876 10 julian.reschke 2010-03-10 09:42:48 +0000 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. 32877 11 mike 2010-03-10 10:24:05 +0000 (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. 32878 12 mike 2010-03-10 10:27:06 +0000 (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. 827 2010-03-10 09:40:51 +0000 2010-03-10 09:40:51 +0000 diffs between the status sections diffs.txt text/plain 4355 julian.reschke MWMxDQo8IFN0YXR1cyBvZiBUaGlzIGRvY3VtZW50DQ0KLS0tDQo+IFN0YXR1cyBvZiB0aGlzIGRv Y3VtZW50DQ0KNSw3YzUsMTgNCjwgY3VycmVudCBXM0MgcHVibGljYXRpb25zIGFuZCB0aGUgbW9z dCByZWNlbnRseSBmb3JtYWxseSBwdWJsaXNoZWQgDQo8IHJldmlzaW9uIG9mIHRoaXMgdGVjaG5p Y2FsIHJlcG9ydCBjYW4gYmUgZm91bmQgaW4gdGhlIFczQyB0ZWNobmljYWwgDQo8IHJlcG9ydHMg aW5kZXggYXQgaHR0cDovL3d3dy53My5vcmcvVFIvLg0NCi0tLQ0KPiBjdXJyZW50IFczQyBwdWJs aWNhdGlvbnMgYW5kIHRoZSBsYXRlc3QgcmV2aXNpb24gb2YgdGhpcyB0ZWNobmljYWwgDQo+IHJl cG9ydCBjYW4gYmUgZm91bmQgaW4gdGhlIFczQyB0ZWNobmljYWwgcmVwb3J0cyBpbmRleCBhdCAN Cj4gaHR0cDovL3d3dy53My5vcmcvVFIvLg0NCj4gDQ0KPiBUaGlzIGlzIGEgV29ya2luZyBEcmFm dCBvZiB0aGUgIkhUTUwrUkRGYTogQSBtZWNoYW5pc20gZm9yIGVtYmVkZGluZyANCj4gUkRGIGlu IEhUTUwiIHNwZWNpZmljYXRpb24gZm9yIHJldmlldyBieSBXM0MgbWVtYmVycyBhbmQgb3RoZXIg DQo+IGludGVyZXN0ZWQgcGFydGllcy4NDQo+IA0NCj4gVGhpcyBXb3JraW5nIERyYWZ0IGluY2x1 ZGVzIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNDQo+IA0NCj4gICAgICogVXBkYXRpbmcgSFRNTDUg Y29lcmNpb24gdG8gSW5mb3NldCBydWxlcyAobm9ybWF0aXZlKQ0NCj4gICAgICogQ2xhcmlmeWlu ZyBob3cgdG8gZXh0cmFjdCBSREZhIGF0dHJpYnV0ZXMgdmlhIEluZm9zZXQgDQo+IChpbmZvcm1h dGl2ZSkNDQo+ICAgICAqIENsYXJpZnlpbmcgaG93IHRvIGV4dHJhY3QgUkRGYSBhdHRyaWJ1dGVz IHZpYSBET00yIChpbmZvcm1hdGl2ZSkNDQoxMCwxOWMyMSwyMw0KPCB0byBwdWJsaWMtaHRtbC1j b21tZW50c0B3My5vcmcgKHN1YnNjcmliZSwgYXJjaGl2ZXMpIG9yIA0KPCB3aGF0d2dAd2hhdHdn Lm9yZyAoc3Vic2NyaWJlLCBhcmNoaXZlcyksIG9yIHN1Ym1pdCB0aGVtIHVzaW5nIG91ciANCjwg cHVibGljIGJ1ZyBkYXRhYmFzZS4gQWxsIGZlZWRiYWNrIGlzIHdlbGNvbWUuDQ0KPCANDQo8IFRo ZSB3b3JraW5nIGdyb3VwcyBtYWludGFpbnMgYSBsaXN0IG9mIGFsbCBidWcgcmVwb3J0cyB0aGF0 IHRoZSBlZGl0b3IgDQo8IGhhcyBub3QgeWV0IHRyaWVkIHRvIGFkZHJlc3MgYW5kIGEgbGlzdCBv ZiBpc3N1ZXMgZm9yIHdoaWNoIHRoZSBjaGFpcnMgDQo8IGhhdmUgbm90IHlldCBkZWNsYXJlZCBh IGRlY2lzaW9uLiBUaGUgZWRpdG9yIGFsc28gbWFpbnRhaW5zIGEgbGlzdCBvZiANCjwgYWxsIGUt bWFpbHMgdGhhdCBoZSBoYXMgbm90IHlldCB0cmllZCB0byBhZGRyZXNzLiBUaGVzZSBidWdzLCBp c3N1ZXMsIA0KPCBhbmQgZS1tYWlscyBhcHBseSB0byBtdWx0aXBsZSBIVE1MLXJlbGF0ZWQgc3Bl Y2lmaWNhdGlvbnMsIG5vdCBqdXN0IA0KPCB0aGlzIG9uZS4NDQotLS0NCj4gdG8gcHVibGljLXJk Zi1pbi14aHRtbC10ZkB3My5vcmcgKHN1YnNjcmliZSwgYXJjaGl2ZXMpIG9yIHRvIA0KPiBwdWJs aWMtaHRtbC1jb21tZW50c0B3My5vcmcgKHN1YnNjcmliZSwgYXJjaGl2ZXMpLCBvciBzdWJtaXQg dGhlbSB1c2luZyANCj4gdGhlIFczQydzIHB1YmxpYyBidWcgZGF0YWJhc2UuDQ0KMjQsMjZjMjgs MzQNCjwgd2F5cy4gVmVuZG9ycyBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyB0aGlzIHNwZWNp ZmljYXRpb24gYmVmb3JlIGl0IA0KPCBldmVudHVhbGx5IHJlYWNoZXMgdGhlIENhbmRpZGF0ZSBS ZWNvbW1lbmRhdGlvbiBzdGFnZSBzaG91bGQgam9pbiB0aGUgDQo8IGFmb3JlbWVudGlvbmVkIG1h aWxpbmcgbGlzdHMgYW5kIHRha2UgcGFydCBpbiB0aGUgZGlzY3Vzc2lvbnMuDQ0KLS0tDQo+IHdh eXMuIFZlbmRvcnMgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgdGhpcyBzcGVjaWZpY2F0aW9u IHNob3VsZCBub3RlIA0KPiB0aGUgc3RhdHVzLCBhbmQgYXJlIGVuY291cmFnZWQgdG8gam9pbiB0 aGUgUkRGYSBXb3JraW5nIEdyb3VwLg0NCj4gDQ0KPiBQdWJsaWNhdGlvbiBhcyBhIFdvcmtpbmcg RHJhZnQgZG9lcyBub3QgaW1wbHkgZW5kb3JzZW1lbnQgYnkgdGhlIFczQyANCj4gTWVtYmVyc2hp cC4gVGhpcyBpcyBhIGRyYWZ0IGRvY3VtZW50IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQg b3IgDQo+IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gY2l0ZSANCj4gdGhpcyBkb2N1bWVudCBhcyBvdGhlciB0aGFuIHdvcmsg aW4gcHJvZ3Jlc3MuDQ0KMzcsNzBjNDUsNTENCjwgaXMgYWx3YXlzIGF2YWlsYWJsZSBvbiB0aGUg VzNDIENWUyBzZXJ2ZXIgYW5kIGluIHRoZSBXSEFUV0cgU3VidmVyc2lvbiANCjwgcmVwb3NpdG9y eS4gVGhlIGxhdGVzdCBlZGl0b3IncyB3b3JraW5nIGNvcHkgKHdoaWNoIG1heSBjb250YWluIA0K PCB1bmZpbmlzaGVkIHRleHQgaW4gdGhlIHByb2Nlc3Mgb2YgYmVpbmcgcHJlcGFyZWQpIGNvbnRh aW5zIHRoZSBsYXRlc3QgDQo8IGRyYWZ0IHRleHQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIChhbW9u Z3N0IG90aGVycykuIEZvciBtb3JlIGRldGFpbHMsIA0KPCBwbGVhc2Ugc2VlIHRoZSBXSEFUV0cg RkFRLg0NCjwgDQ0KPCBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRvIGZvbGxvdyB0aGUgY2hhbmdl IGhpc3RvcnkgZm9yIHRoZSBIVE1MIA0KPCBzcGVjaWZpY2F0aW9uczoNDQo8IA0NCjwgRS1tYWls IG5vdGlmaWNhdGlvbnMgb2YgY2hhbmdlcw0NCjwgICAgIEhUTUwtRGlmZnMgbWFpbGluZyBsaXN0 IChkaWZmLW1hcmtlZCBIVE1MIHZlcnNpb25zIGZvciBlYWNoIA0KPCBjaGFuZ2UpOiBodHRwOi8v bGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtaHRtbC1kaWZmcy9sYXRlc3QNDQo8 ICAgICBDb21taXQtV2F0Y2hlcnMgbWFpbGluZyBsaXN0IChjb21wbGV0ZSBzb3VyY2UgZGlmZnMp OiANCjwgaHR0cDovL2xpc3RzLndoYXR3Zy5vcmcvbGlzdGluZm8uY2dpL2NvbW1pdC13YXRjaGVy cy13aGF0d2cub3JnDQ0KPCBSZWFsLXRpbWUgbm90aWZpY2F0aW9ucyBvZiBjaGFuZ2VzOg0NCjwg ICAgIEdlbmVyYXRlZCBkaWZmLW1hcmtlZCBIVE1MIHZlcnNpb25zIGZvciBlYWNoIGNoYW5nZTog DQo8IGh0dHA6Ly90d2l0dGVyLmNvbS9IVE1MNQ0NCjwgICAgIEFsbCAobm9uLWVkaXRvcmlhbCkg Y2hhbmdlcyB0byB0aGUgc3BlYyBzb3VyY2U6IA0KPCBodHRwOi8vdHdpdHRlci5jb20vV0hBVFdH DQ0KPCBCcm93c2FibGUgdmVyc2lvbi1jb250cm9sIHJlY29yZCBvZiBhbGwgY2hhbmdlczoNDQo8 ICAgICBDVlNXZWIgaW50ZXJmYWNlIHdpdGggc2lkZS1ieS1zaWRlIGRpZmZzOiANCjwgaHR0cDov L2Rldi53My5vcmcvY3Zzd2ViL2h0bWw1Lw0NCjwgICAgIEFubm90YXRlZCBzdW1tYXJ5IHdpdGgg dW5pZmllZCBkaWZmczogDQo8IGh0dHA6Ly9odG1sNS5vcmcvdG9vbHMvd2ViLWFwcHMtdHJhY2tl cg0NCjwgICAgIFJhdyBTdWJ2ZXJzaW9uIGludGVyZmFjZTogc3ZuIGNoZWNrb3V0IA0KPCBodHRw Oi8vc3ZuLndoYXR3Zy5vcmcvd2ViYXBwcy8NDQo8IA0NCjwgVGhlIFczQyBIVE1MIFdvcmtpbmcg R3JvdXAgaXMgdGhlIFczQyB3b3JraW5nIGdyb3VwIHJlc3BvbnNpYmxlIGZvciANCjwgdGhpcyBz cGVjaWZpY2F0aW9uJ3MgcHJvZ3Jlc3MgYWxvbmcgdGhlIFczQyBSZWNvbW1lbmRhdGlvbiB0cmFj ay4gVGhpcyANCjwgc3BlY2lmaWNhdGlvbiBpcyB0aGUgNCBNYXJjaCAyMDEwIEZpcnN0IFB1Ymxp YyBXb3JraW5nIERyYWZ0Lg0NCjwgDQ0KPCBUaGUgY29udGVudHMgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uIGFyZSBhbHNvIHBhcnQgb2YgYSBzcGVjaWZpY2F0aW9uIA0KPCBwdWJsaXNoZWQgYnkgdGhl IFdIQVRXRywgd2hpY2ggaXMgYXZhaWxhYmxlIHVuZGVyIGEgbGljZW5zZSB0aGF0IA0KPCBwZXJt aXRzIHJldXNlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIHRleHQuDQ0KLS0tDQo+IGlzIGFsd2F5cyBh dmFpbGFibGUgb24gdGhlIFczQyBDVlMgc2VydmVyLiBUaGUgbGF0ZXN0IGVkaXRvcidzIHdvcmtp bmcgDQo+IGNvcHkgKHdoaWNoIG1heSBjb250YWluIHVuZmluaXNoZWQgdGV4dCBpbiB0aGUgcHJv Y2VzcyBvZiBiZWluZyANCj4gcHJlcGFyZWQpIGlzIGFsc28gYXZhaWxhYmxlLg0NCj4gDQ0KPiBU aGlzIHNwZWNpZmljYXRpb24gaGFzIGJlZW4gam9pbnRseSBkZXZlbG9wZWQgYnkgdGhlIFJERmEg VGFzayBGb3JjZSANCj4gYW5kIHRoZSBIVE1MIFdvcmtpbmcgR3JvdXAgYW5kIGlzIGN1cnJlbnRs eSBiZWluZyBwdWJsaXNoZWQgYnkgdGhlIEhUTUwgDQo+IFdvcmtpbmcgR3JvdXAgdG8gZnVydGhl ciBkaXNjdXNzaW9ucyB0aGVyZS4NDQo=