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

Ian Hickson wrote:
> ...
> My point wasn't to say that the extension mechanism in question was the 
> same one as for adding vcard types, I know it isn't. My point was that it 
> was further examples of extension mechanisms being a waste of time.
> ...

So, we discuss extension mechanism A, and you point to extension 
mechanism B to support your point?

> But this is moot, since despite my opposition to extension mechanisms, 
> HTML5 has many, including decentralised extension mechanisms, and 
> including mechanisms for handling extensions to vCard (namely, updating 
> the spec).

I wouldn't call that an extension mechanism.

> (Note that in practice, with vCard changing so incompatibly with the new 
> revision, we have another example of the problems with extension 
> mechanisms: almost all the changes vCard will have experienced since its 
> inception will have been changes the extension mechanism couldn't handle. 
> So there's not much point us doing anything to support it more explicitly 
> than just updating the vocabulary as extensions are made.)

I recommend that you bring up this issue in the VCARDDAV working group. 
The main point of ISSUE-73 is that I don't want the HTML WG to spend 
cycles on this.

>>> Extension mechanisms are largely a waste of time. It's better to just 
>>> extend the language directly by updating the relevant spec.
>> Disagreed.
> 
> I've shown a number of examples (just with vCard, even) of real-world 
> scenarios that have led me to hold this position; is your disagreement on 
> idealogical grounds, or do you have any counter-examples?

The fact that some extension mechanisms have failed doesn't prove they 
are a bad idea in general. There are many that have worked perfectly well.

>> You brought up "no normative status whatsoever". I just pointed out that 
>> this is temporary, and also applies to HTML5.
> 
> Are you saying that people who refer to HTML today should refer 
> normatively to HTML5 then? I would have thought you would have preferred 
> that they continue to refer to HTML4 until HTML5 was a standard.

In general yes. In this particular case, we have two specs that are 
currently progressing, and there's little point to refer to the old 
version when we know that the new version differs a lot, and will be 
ready at a similar point of time.

>>> 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?
> 
> In much the same way that the old vCard elements were added. Could you 
> answer my question?

It appears that you are saying that it's sufficient that HTML can be 
extended by creating a new version of the HTML spec. Obviously we 
disagree on this point. It doesn't seem to productive to spend more tome 
on that topic.

> ...
>> So *will* you fix it once draft-ietf-vcarddav-vcardrev is approved for 
>> publication?
> 
> Yes, of course (assuming that the revised draft represents what 
> implementations are interested in supporting, anyway -- I guess there is 
> the chance that the revised draft is ends up being DOA, though I have no 
> reason to believe that will happen in this case).

And whether this is the case will be decided by whom?

> ...
>> You're abusing your editorial power to include things into HTML5 that 
>> you happen to be interested with.
> 
> I personally think microdata (and machine-readable annotation in general) 
> is a horrible waste of time altogether. I wouldn't have any of this 
> section at all if I was writing the spec to be what I was happened to be 
> interested in.
> ...

If you think that microdata is a horrible waste of time then please 
remove it from the spec.

>> 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).
> 
> I don't understand how the predefined vocabularies could not be part of 
> the language. What do you mean by "part of the language"?

Defined by HTML5, or by something it normatively refers to.

>> BTW, I notice that you didn't reply to:
>>
>>> 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.
> 
> I didn't realise there was anything to respond to. Which other things did 
> you have in mind?

I was wondering whether anything that is browser related and affects 
*existing* implementations, and does have *current* interop problems 
merits being addressed by HTML5. In which case I'd like to restart the 
discussion of making requirements on the treatment of 
Content-Disposition (which currently has little interop with respect to 
I18N).

BR, Julian

Received on Thursday, 23 July 2009 07:34:26 UTC