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

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.

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

Actually there is, the registry text is just confusing.

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

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

Understood.

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

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

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

Again, the proposal was that it does not normatively refer to it.

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

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

BR, Julian

Received on Wednesday, 8 July 2009 06:47:44 UTC