W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: CfC: Publish HTML5, RDFa heartbeats and Microdata, 2D Context and H:TML as FPWDs

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 14 Feb 2010 04:39:59 -0800
Cc: Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
Message-id: <6D345207-C671-4C7F-AA0A-1EC38A5CE9FD@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:01 GMT