- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 21 Jul 2009 08:17:14 +0000 (UTC)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Maciej Stachowiak <mjs@apple.com>, "Dailey, David P." <david.dailey@sru.edu>, "public-html@w3.org WG" <public-html@w3.org>
On Wed, 8 Jul 2009, Julian Reschke wrote: > Ian Hickson wrote: > > > Indeed. However I didn't suggest that HTML5 should refer to it at > > > all. Problem gone. > > > > We can't remove the referene to the predefined vocabularies, since > > they're a core part of the drag-and-drop model. That is in fact a key > > part to solving a number of the use cases. > > 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. > > > As far as I can tell, the text does not consider extensions made to > > > RFC2426 through the IANA registry, > > > > Assuming you mean this one: > > > > http://www.iana.org/assignments/text-directory-registrations > > > > ...then there aren't any, so I figured there wasn't much point going > > out of my way to support them. > > Actually there is, the registry text is just confusing. 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. > But even if that wouldn't be the case, it's not up to you to remove > extensibility features from other formats. The vCard format isn't affected at all here, it's only the vocabulary that we are adopting, and it is being placed into a format with just as many if not more extension mechanisms. > > > nor extensions being defined in RFC2426bis > > > (draft-ietf-vcarddav-vcardrev), thus they wouldn't be covered by the > > > spec. > > > > I expect to update the vocabulary once the RFC has been updated. > > 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. > > > > > Parsing - for some types, parsing rules are being rephrased from > > > > > RFC2426. There is a risk that they diverge. > > > > Could you be more specific? > > > This is part of the problem. Of course people *could* review that part in > > > detail, but it costs time, > > > > Splitting them out wouldn't change that... > > 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. > > > That being said, "tel" may be an instance of this issue; the text in > > > HTML5, RFC2426 and RFC2426bis differ. > > > > HTML5 and RFC2426 seem to say the same thing as far as I can tell; > > RFC2426bis makes an incompatible change here. It seems wiser to follow > > the 11 year old specification here than the proposal. > > 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. > > > > > Versioning - the IETF is revising vCard, see > > > > > <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-07>. Is HTML5 > > > > > going to freeze the vocabulary at a version that the IETF is currently > > > > > obsoleting? > > > > I don't see any reason why we would, no. In fact I was informed by the > > > > calsify work in the development of the vEvent section (for example I did > > > > not provide anything but the minimum support for repeating events, since > > > > it is proposed to remove them). > > > So *did* you contact the IETF VCARDDAV working group? > > > (<http://tools.ietf.org/wg/vcarddav/>) > > > > Nope. > > 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 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 21 July 2009 08:18:01 UTC