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

It is the best practice in standards organizations to
allow orthogonal technologies to be updated and extended 
independently. While it may be convenient to establish
a mandatory-to-implement baseline, in such cases the baseline
should be documented by reference, not inclusion.

The simple reason is that the alternative requires
a process which cannot be sustained: to keep a 
committee alive for an indefinite period merely so
the spec can be updated to accommodate interoperability
with other applications that are also evolving.

This principle applies for character sets, image formats, 
URI schemes, networking protocols, video codecs, and
in this case, vocabularies, including vCard vocabularies.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Ian Hickson
Sent: Wednesday, July 22, 2009 11:48 PM
To: julian.reschke@gmx.de
Cc: public-html@w3.org WG
Subject: Re: ISSUE-73 (Overlap of "predefined vocabularies" with other specifications), was: Concerns about new section "predefined vocabularies"

On Tue, 21 Jul 2009, Julian Reschke wrote:
> > 
> > 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>.

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.

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).

(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.)


> > 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?


> > > > 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.

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.


> > 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?


> > > 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?

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).


> > > 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.

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.


> > > 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).

I don't understand how the predefined vocabularies could not be part of 
the language. What do you mean by "part of the language"?


> 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?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 23 July 2009 21:34:29 UTC