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

On Wed, 8 Jul 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > > Indeed. However I didn't suggest that HTML5 should refer to it at 
> > > all. Problem gone.
> > 
> > We can't remove the referene to the predefined vocabularies, since 
> > they're a core part of the drag-and-drop model. That is in fact a key 
> > part to solving a number of the use cases.
> 
> 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.


> > > As far as I can tell, the text does not consider extensions made to 
> > > RFC2426 through the IANA registry,
> > 
> > Assuming you mean this one:
> > 
> >    http://www.iana.org/assignments/text-directory-registrations
> > 
> > ...then there aren't any, so I figured there wasn't much point going 
> > out of my way to support them.
> 
> Actually there is, the registry text is just confusing.

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.


> But even if that wouldn't be the case, it's not up to you to remove 
> extensibility features from other formats.

The vCard format isn't affected at all here, it's only the vocabulary that 
we are adopting, and it is being placed into a format with just as many if 
not more extension mechanisms.


> > > nor extensions being defined in RFC2426bis 
> > > (draft-ietf-vcarddav-vcardrev), thus they wouldn't be covered by the 
> > > spec.
> > 
> > I expect to update the vocabulary once the RFC has been updated.
> 
> 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.


> > > > > Parsing - for some types, parsing rules are being rephrased from
> > > > > RFC2426. There is a risk that they diverge.
> > > > Could you be more specific?
> > > This is part of the problem. Of course people *could* review that part in
> > > detail, but it costs time,
> > 
> > Splitting them out wouldn't change that...
> 
> It would. As part of HTML5, at some point of time I'll have to form an 
> opinion about it. As some other spec, I can choose to ignore it.

So you're saying it'll get _more_ review if we leave it in the spec? That 
seems like a strong reason to leave it in.


> > > That being said, "tel" may be an instance of this issue; the text in 
> > > HTML5, RFC2426 and RFC2426bis differ.
> > 
> > HTML5 and RFC2426 seem to say the same thing as far as I can tell; 
> > RFC2426bis makes an incompatible change here. It seems wiser to follow 
> > the 11 year old specification here than the proposal.
> 
> 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.


> > > > > Versioning - the IETF is revising vCard, see
> > > > > <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-07>. Is HTML5
> > > > > going to freeze the vocabulary at a version that the IETF is currently
> > > > > obsoleting?
> > > > I don't see any reason why we would, no. In fact I was informed by the
> > > > calsify work in the development of the vEvent section (for example I did
> > > > not provide anything but the minimum support for repeating events, since
> > > > it is proposed to remove them).
> > > So *did* you contact the IETF VCARDDAV working group?
> > > (<http://tools.ietf.org/wg/vcarddav/>)
> > 
> > Nope.
> 
> 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 
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.

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

Received on Tuesday, 21 July 2009 08:18:01 UTC