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:
> Ian Hickson wrote:
> > > I don't think that there is consensus that HTML5 needs to address 
> > > these use cases.
> > 
> > I'm not a big fan of them myself, but there seemed to be quite a lot 
> > of requests for them. I'm not sure what you mean by consensus in this 
> > context though.
> 
> It's not in the charter, and there's certainly no consensus whatsoever 
> in the W3C HTML WG that it needs to be addressed by HTML5.

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


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

Extension mechanisms are largely a waste of time. It's better to just 
extend the language directly by updating the relevant spec.

Having said that, I really don't think that defining the vocabulary in 
terms of a registry would be a useful use of anyone's time even if 
extension mechanisms _were_ to be a useful concept for more than just spec 
writing.


> > > And from that one? You'll update HTML5 every time new extensions are
> > > defined through the IETF process?
> > 
> > Given how rarely it happens, yes, that seems like the option that involves
> > the least amount of work and has the greatest chance of resulting in
> > interoperable, reliable software.
> 
> Disagreed.

Ok.


> > > > It's not up to you to decide that. If you think that the relevant
> > > standards body is making a mistake, follow up where that spec is 
> > > being developed.
> > 
> > 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...?


> > > So it appears you're unwilling to cooperate with those people who 
> > > own that spec. Unfortunate.
> > 
> > I really don't understand what there is to cooperate about. I'm quite 
> > happy to cooperate, I just don't see what that would mean in this 
> > instance. It's not like we're redesigning vEvent or anything here; all
> 
> You removed an extension point, as far as I can tell.

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?


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


> > that the HTML5 spec is doing is documenting how the vEvent vocabulary 
> > can be cast as a microdata format. It follows the original faithfully, 
> > and can in future follow subsequent versions if that turns out to be 
> > the right thing to do.
> > 
> > Having said that, if you would like to act as liason, that would be 
> > very welcome. Please let me know if there's anything I can do to help.
> 
> 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.


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

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

Received on Tuesday, 21 July 2009 11:40:41 UTC