- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 14 Feb 2010 04:39:59 -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 14, 2010, at 3:05 AM, Julian Reschke wrote: > Maciej Stachowiak wrote: >> On Feb 11, 2010, at 6:35 AM, Julian Reschke wrote: >>> >>> Finally, more alignment with the sister specification (RDFa) would >>> be good. It currently 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." >>> >>> which I think is very helpful in understanding the status of these >>> documents. >> How about if we handle concerns with the documents with the same >> kinds of issue markers that the HTML5 draft has, as suggested by >> Sam? Linking to an issue and stating that it blocks progress to >> Last Call seems to be completely uncontroversial. However, markers >> that put the wording of the objection inline and don't link to an >> issue seem to cause arguments. >> ... > > That sounds *technically* plausible, but... Do we really want to > publish documents that have open issues attached to "Status of this > Document"??? No, I am assuming there are substantive issues with parts of the spec, and that expressing them as bugs (and, if necessary, issues) would result in the proper status markers. For example, looking at the statement "There are one or more alternate methods of adding data without using RDFa, such as [microdata]," I assume there is some bug report we could file, which if fixed would allow us to resolve that issue. Or if the editor refused to fix it, and someone cared to escalate it to an issue, and someone could write a concrete Change Proposal which would resolve the issue. I'm not entirely sure what the bug report would say, but I presume the people who want this issue flagged in the spec know what the problem is, have an idea about how to fix it, and can file the appropriate bug. If we do it that way, then we'll have a clear process for what to do about the issue marker and when to remove it. > If this text is OK for RDFa, why isn't it OK for Microdata? Could > you please elaborate? > > We very clearly decided last month that Microdata and RDFa+in-HTML > should have the same status. The Status section should reflect that. > I'm not married to the exact wording, but I'd like to see > consistency in both drafts. Manu chose to use that wording after hearing people's feedback on the status section. I don't think treating both drafts equally means we should order Ian to change his status wording to be the same as what Manu used, nor do I think we should order Manu to use the same wording that Ian used. I think treating them equally means subjecting both to the same process for people to express their concerns. Of course, any editor is welcome to voluntarily flag additional concerns in the spec. But I am not going to order anyone to do so if the people who have that concern is not even willing to go to the effort of filing a bug. Regards, Maciej
Received on Sunday, 14 February 2010 12:40:34 UTC