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

On Wed, 10 Jun 2009, Julian Reschke wrote:
> > > 
> > > Spec Size - the spec already is big, and there is no evidence that 
> > > this needs to be specified *inside* the HTML5 spec.
> > 
> > Whether it is specified within the same document or in a separate 
> > document to which HTML5 normatively refers doesn't seem to make any 
> > difference to the complexity of the platform. I don't understand the 
> > desire to exchange fewer larger documents for more smaller documents.
> 
> 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.


> > > Extensibility - the current chapter copies terminology from RFC2426, 
> > > but misses it's extensibility hooks, and thus fails to mention 
> > > things that have been defined later, such as the IMPP type name.
> > 
> > Could you elaborate on this? As far as I can tell the microdata 
> > mechanism is quite extensible.
> 
> 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.

(I don't share your enthusiasm regarding extension mechanisms in general.)


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


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


> and the spec is already too big anyway.

As I said above, whether it is specified within the same document or in a 
separate document to which HTML5 normatively refers doesn't seem to make 
any difference to the complexity of the platform. I don't understand the 
desire to exchange fewer larger documents for more smaller documents.


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


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

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

Received on Wednesday, 8 July 2009 01:32:59 UTC