- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 21 Jul 2009 13:53:59 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org WG" <public-html@w3.org>
Ian Hickson wrote: >>From the charter: "A language evolved from HTML4 for describing the > semantics of documents and applications on the World Wide Web. This will > be a complete specification [...]". > > Events, contact information, and licensing are all part of documents, > according to the many long e-mails I have received on the subject over the > past year or so primarily from people involved in W3C work. So *anything* that appears in documents is in scope? That's news to me. >>> 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> > > The very first bullet point there pretty much summarises my argument: > > # [RFC2425] and [RFC2426] have been merged. Initially [RFC2425] was > # intended to be extensible but only 2426 ever extended it. I recommend you look at the two RFCs, then you'll realize this refers to a different topic. The VCARD extensibility mechanism is defined in <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-08#section-11.2>. > Extension mechanisms are largely a waste of time. It's better to just > extend the language directly by updating the relevant spec. Disagreed. > ... >>> 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...? You brought up "no normative status whatsoever". I just pointed out that this is temporary, and also applies to HTML5. > ... > Could you explain exactly how the extension point was removed? As far as I > can tell, I just took an existing vocabulary that was associated with a > format with an extension mechanism, and put it in a different format with > a different extension mechanism, all the while leaving it very easy to > extend the definition of the vocabulary in the new format so as to take > into account any future additions to the original vocabulary. Could you > elaborate on why that is wrong, or what is bad about it? > ... So once new VCARD elements get defined, how will they be added to HTML5? >> And you are hard-wiring something that's going to be obsoleted in IETF >> soonish. > > We can fix it as soon as it is obsolete. I really don't understand the > problem here. Are you saying that the IETF should not have released > RFC2426 because it was going to be made obsolete also? So *will* you fix it once draft-ietf-vcarddav-vcardrev is approved for publication? > ... >> Just drop the section from HTML5, and define it in a separate document. > > How would that make the slightest difference to any of the concerns you > have raised? So far all you've said is that the only reason we should put > it into another spec is so that you can ignore it and not form an opinion, > but as far as I can tell, that's a net loss for us. You're abusing your editorial power to include things into HTML5 that you happen to be interested with. >> And no, without having HTML5 normatively refer to it. > > It's part of the language. Whether there's an explicit normative reference > or an implicit import through a back-reference doesn't seem to matter. The proposal is *not* to make it part of the language. (And, btw, I've seen several other people agreeing with that, favoring a more generic approach instead). BTW, I notice that you didn't reply to: JR> 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. BR, Julian
Received on Tuesday, 21 July 2009 11:54:52 UTC