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

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