Re: HTML+RDFa Heartbeat Draft publishing request

On Jan 15, 2010, at 7:54 AM, Larry Masinter wrote:

> Are you saying the charter's language covers the extensibility
> mechanisms being discussed under ISSUE-41? Is your reading is
> that it also covers additional extensibility mechanisms,
> including the one being proposed in HTML+RDFa (which may
> or may not fit within the ISSUE-41 category) and the one
> proposed for Microdata (which doesn't fit under ISSUE-41
> at all?) Is your interpretation of the charter that it
> allows the working group to consider any extensibility
> mechanisms at all, whether or not it allows *any* of the
> suggested vocabularies, and whether or not ISSUE-41 is
> resolved satisfactorily?

In my personal view, I would answer "yes" to the above questions. I  
would also add the clarification that extension mechanisms, to fall  
under this clause of the charter, should allow mixing of at least some  
independently developed vocabularies, though not necessarily one or  
more of the example ones.  (I have not discussed this issue with my co- 
Chairs, the Team Contacts, or any other representatives of the W3C  
Team, so this is strictly a personal opinion at this point).


>
> I understand the way of taking mechanisms A, B and C to
> allow P, Q and R respectively, and saying "there is one
> mechanism X which consists of using one of A, B or C to
> allow P, Q, and R respectively", which means that you
> say you have "a" mechanism "X", it just has some options.
>
> But if you don't allow P or Q at all, and wind up with
> mechanisms C and D, which don't allow P or Q and just
> allows R and S, I don't see how those, by themselves,
> could be construed as "a" mechanism "Y" (consisting of
> C or D) which allows "P, Q and R" since it doesn't
> allow P or Q. I don't think you've matched what the
> charter calls for.

In my view, the charter does not call for supporting any list  
explicitly. It says "such as Internationalization Tag Set (ITS), Ruby,  
and RDFa". My understanding of English is that "such as" introduces a  
subordinate clause listing illustrative examples, not a definitional  
list. For example, if I say "I'd like to paint my room a primary color  
such as red or green", then if I actually paint my room blue, I have  
not reneged on my claim.

> I can see how you might think that
> it still furthers the goals of the working group to
> address extensibility, and that the charter language
> is just an "encouragement" and how we do things that
> aren't listed exactly in the charter.
>
>> Some might even propose removing some of the
>> existing mechanisms in the course of adding new ones,
>> though I do not believe anyone has actually advocated that view.
>
> The removal of header/@profile and !DOCTYPE version-specific
> behavior are examples of removing 'existing' extensibility
> mechanisms. Those have actually been advocated. Do you disagree
> that those were existing mechanisms? Or that anyone had
> advocated the view of removing them?

I personally do not see @profile and especially DOCTYPE versioning as  
extensibility mechanisms, but I can see how others may view them that  
way, so I concede the point.

>
> Do you agree the introduction of microdata as an alternative
> way of  satisfying RDFa requirements might not be a
> 'removal', but it was advocating an alternative to one
> of the proposed vocabularies & extension mechanisms?

It was indeed advocating an alternative, and the Working Group has  
decided to allow both alternatives to progress independently.

>
> It would seem to me we could just as well delay publication
> of microdata as an extensibility mechanism until ISSUE-41
> is resolved, since that has a finite conclusion, and
> we can then evaluate how the microdata mechanism would
> interact with whatever the resolution of ISSUE-41
> might be.

That could take several months. I would rather not delay in the  
meantime. We can always choose to abandon a piece of work in the  
future. If we have to do that without the buy-in of the respective  
editor, then the ultimate mechanism would be an Issue and Change  
Proposal against that draft, that changes its status to non-normative  
and adds a clear indication that the work is abandoned. If a Last Call  
resolution failed, we would also consider such measures. My own  
preference would be to give proposed drafts a chance to show their  
value, as long as they are bona-fide products of the Working Group and  
reasonably related to our work.

>
> Another alternative would be to note in those
> drafts themselves their interaction with ISSUE-41,
> and the mechanisms in them, or their inclusion in
> HTML at all, might change depending on the resolution of
> ISSUE-41?

We can make sure all the affected drafts have an ISSUE-41 issue  
marker, like the numerous issue markers already in the HTML5 main spec.

>
> It's not clear how the mechanism we established to note
> open issues in the original HTML document applies to
> these additional drafts, or whether that work needs
> to be applied manually.

I am not sure either. I believe it would be easy to apply to the  
Microdata draft, since it goes through the same toolchain. I think  
Manu would know how practical it is for the HTML+RDFa draft.

Regards,
Maciej

Received on Friday, 15 January 2010 19:17:44 UTC