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

Ian Hickson wrote:
> On Wed, 13 May 2009, Julian Reschke wrote:
>> I'm very concerned about what's going on here in the spec -- see 
>> <http://dev.w3.org/html5/spec/Overview.html#vcard>.
>>
>> This mainly replicates information from the IETF vCard spec (RFC 2739). 
>> I realize that the author may think that that spec is not sufficient; 
>> but the right way to fix this is to participate in revising it (see 
>> <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-07> and 
>> <http://tools.ietf.org/wg/vcarddav/>), not by creating a copy in W3C 
>> space.
> 
> The intent is not to replicate any information but to describe how to 
> reuse the preexisting vocabulary in a new serialisation.

Not sure how the intent is relevant when the outcome is that it *does* 
replicate information.

> On Thu, 14 May 2009, Julian Reschke wrote:
>> In the meantime, the spec also replicates information from RFC 2446 
>> (iCalendar), soon to be obsoleted by 
>> <http://tools.ietf.org/html/draft-ietf-calsify-2446bis-09>. See 
>> <http://dev.w3.org/html5/spec/Overview.html#vevent>.
> 
> This is similarly not replicating information but attempting to merely 
> describe the rules by which one can reuse a well-established preexisting 
> vocabulary in a new syntax.
> ...

Same discussion.

> On Fri, 15 May 2009, Julian Reschke wrote:
>> Procedural - the WG is working on trying to find consensus on all 
>> sections of the spec; sections without consensus are to be removed (at 
>> least that's my understanding of the process). Also, the editor himself 
>> announced a "feature freeze" quite some time ago. So, why are we seeing 
>> these new sections without *any* prior discussion?
> 
> There were literally months if not years of prior discussion on these use 
> cases (primarily on the list hosted by the WHATWG, which this working 
> group is chartered to work with).

I appears your understanding of "feature freeze" differs from mine.

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

>> 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, nor extensions being defined in 
RFC2426bis (draft-ietf-vcarddav-vcardrev), thus they wouldn't be covered 
by the spec.

>> 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, and the spec is already too big anyway.

That being said, "tel" may be an instance of this issue; the text in 
HTML5, RFC2426 and RFC2426bis differ.

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

BR, Julian

Received on Wednesday, 10 June 2009 08:32:52 UTC