W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: ISSUE-73 (Overlap of "predefined vocabularies" with other specifications), was: Concerns about new section "predefined vocabularies"

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 21 Jul 2009 11:39:23 +0200
Message-ID: <4A658CCB.2040303@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Maciej Stachowiak <mjs@apple.com>, "Dailey, David P." <david.dailey@sru.edu>, "public-html@w3.org WG" <public-html@w3.org>
Ian Hickson wrote:
>> I don't think that there is consensus that HTML5 needs to address these 
>> use cases.
> 
> I'm not a big fan of them myself, but there seemed to be quite a lot of 
> requests for them. I'm not sure what you mean by consensus in this context 
> though.

It's not in the charter, and there's certainly no consensus whatsoever 
in the W3C HTML WG that it needs to be addressed by HTML5.

> Ah, I see, the IMPP type. I have added it to the spec.
> 
> Given that at the current rate the HTML language is being updated more 
> frequently than this registry is getting extensions (even with the 
> half-decade break that the HTML language took!), I figure we can just 
> track the registry if more terms are added. There's no need to add some 
> complicated mechanism to track the registry.

<http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-08#appendix-A>

> ...
>> And from that one? You'll update HTML5 every time new extensions are 
>> defined through the IETF process?
> 
> Given how rarely it happens, yes, that seems like the option that involves 
> the least amount of work and has the greatest chance of resulting in 
> interoperable, reliable software.
> ...

Disagreed.

> ...
>> It would. As part of HTML5, at some point of time I'll have to form an 
>> opinion about it. As some other spec, I can choose to ignore it.
> 
> So you're saying it'll get _more_ review if we leave it in the spec? That 
> seems like a strong reason to leave it in.
> ...

But then, it would be a reason to add lots of other things as well. Some 
of which being more important, and related to *existing* interop 
problems of UAs, btw.

So no, this doesn't scale.

> ...
>>> It's not up to you to decide that. If you think that the relevant 
>> standards body is making a mistake, follow up where that spec is being 
>> developed.
> 
> Even if I thought the new text is better (I have no opinion on the 
> matter), my point is that one is an 11-year-old spec, and the other has no 
> normative status whatsoever.
> ....

Has no normative status *yet*. The same applies to HTML5.

> ...
>> So it appears you're unwilling to cooperate with those people who own that
>> spec. Unfortunate.
> 
> I really don't understand what there is to cooperate about. I'm quite 
> happy to cooperate, I just don't see what that would mean in this 
> instance. It's not like we're redesigning vEvent or anything here; all 

You removed an extension point, as far as I can tell. And you are 
hard-wiring something that's going to be obsoleted in IETF soonish.

> that the HTML5 spec is doing is documenting how the vEvent vocabulary can 
> be cast as a microdata format. It follows the original faithfully, and can 
> in future follow subsequent versions if that turns out to be the right 
> thing to do.
> 
> Having said that, if you would like to act as liason, that would be very 
> welcome. Please let me know if there's anything I can do to help.

Just drop the section from HTML5, and define it in a separate document. 
And no, without having HTML5 normatively refer to it.

BR, Julian
Received on Tuesday, 21 July 2009 09:40:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC