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

On Thu, 23 Jul 2009, Julian Reschke wrote:
> > 
> > (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. 

I don't think it's an issue. I'm just illustrating the reasons for my 
dislike of extension mechanisms.


> The main point of ISSUE-73 is that I don't want the HTML WG to spend 
> cycles on this.

Ironically, the only reason we are spending any cycles on this at all in 
the HTML WG is that you filed this issue. I'd be happy to stop discussing 
it, if your only concern is that we not discuss it.


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

Could you name some? I'm aware of some that have worked adequately, such 
as the class="" attribute in HTML, but I think it would be a stretch to 
say that any Web technology has had non-spec-based extension mechanisms 
that have worked "perfectly".


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

I would hope that the new vCard specification will be done decades before 
HTML5 is done. They don't appear to be on similar trajectories at all.


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

Very well, but since you haven't substantiated your disagreement, and 
since it seems to be crucial to the question of how we reuse the vCard 
vocabulary, it will be unlikely that arguments that support your position 
will be raised if we don't discuss it.


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

Implementors, presumably. Who else can decide whether a spec is adopted?


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

Again, I am not editing HTML5 to be what I want it to be, I'm editing it 
to be the best technical solution that I can find for the problems that 
people have raised. Despite my personal opinions on the topic, many people 
do in fact seem to care about these use cases, and so it would be remiss 
of me to ignore them.


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

By "part of the language" I mean a feature that HTML authors can use as a 
first-class feature. We could take the HTML parsing section out of the 
HTML5 spec, define it in another document, and not explicitly or 
normatively reference it, but that wouldn't make the syntax stop being 
part of the HTML language.

So again, the predefined vocabularies are part of the language. Whether 
there's an explicit normative reference or an implicit import through a 
back-reference doesn't seem to matter, except that the former is far 
clearer to readers.


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

I'm sure the HTTP working group specs get plenty of review without having 
to piggy back on the HTML5 spec.

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

Received on Friday, 24 July 2009 04:28:05 UTC