RE: HTML+RDFa Heartbeat Draft publishing request

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?

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. 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?

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 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. 

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?

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.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Thursday, January 14, 2010 9:41 AM
To: Larry Masinter
Cc: julian.reschke@gmx.de; Lachlan Hunt; Michael Hausenblas; www-archive; Ian Hickson
Subject: Re: HTML+RDFa Heartbeat Draft publishing request


On Jan 14, 2010, at 9:34 AM, Larry Masinter wrote:

> Well, if ISSUE-41 is how the HTML-WG is addressing the
> extensibility mechanism in the charter, then what again
> is the rationale for adding microdata?

ISSUE-41 covers a particular family of proposals for additional  
extensibility. Some of those proposals may build on the already  
existing extensibility mechanisms. Others may propose brand new  
additional mechanisms. 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. My hope is that when  
ISSUE-41 is settled, we will have a good picture of the overall range  
of extensibility mechanisms we plan to offer, and how that lines up  
with the charter's encouragement.

Regards,
Maciej

>
> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Thursday, January 14, 2010 8:47 AM
> To: Larry Masinter
> Cc: julian.reschke@gmx.de; Lachlan Hunt; Michael Hausenblas; www- 
> archive; Ian Hickson
> Subject: Re: HTML+RDFa Heartbeat Draft publishing request
>
> Hi Larry,
>
> On Jan 14, 2010, at 8:38 AM, Larry Masinter wrote:
>
>> I think where this discussion is leading me is:
>>
>> HTML has several different extension mechanisms.
>> Some traditional extensibility mechanisms (DOCTYPE version
>> extensions & DTDs, head/@profile with meta) have been
>> removed.
>>
>> Some new ones have been proposed and added
>> (microdata) or added under protest (RDFa).
>>
>> Some other ones are being dealt with a mysterious
>> "other specification" mechanism which isn't really
>> a mechanism since it isn't really defined.
>> (SVG and MathML).
>>
>> Some other namespace-like things are being discussed
>> but haven't been settled.
>>
>> One of the proposals shows how to add RDFa but
>> nothing else, there's a proposal for how to add Ruby
>> which we haven't talked about much. I don't remember
>> any discussions on how to add ITS.
>>
>> No one has talked much about how to unify these
>> extensibility mechanisms or enable a transition of
>> one to the other.
>>
>> I think if we were going to take the charter seriously,
>> we'd do more work on convergence.
>>
>> Is that a fair summary? Would you change it somehow?
>
> I think that in broad terms you are correct that we should consider
> extension mechanisms more generally, and see if any broadly powerful
> ones need to be added. I believe that is covered under ISSUE-41
> decentralized-extensibility, where we have had much discussion and
> soon will need to convert our thinking into concrete proposals.
>
> I'm not sure I agree entirely with all of your specific comments, but
> I'm thinking I will save that commentary for the ISSUE-41 discussion.
>
> Regards,
> Maciej
>

Received on Friday, 15 January 2010 15:54:58 UTC