- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 21 Jul 2009 11:39:23 +0200
- 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