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
