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

Ian Hickson wrote:
> ...
>> The main point of ISSUE-73 is that I don't want the HTML WG to spend 
>> cycles on this.
> 
> Ironically, the only reason we are spending any cycles on this at all in 
> the HTML WG is that you filed this issue. I'd be happy to stop discussing 
> it, if your only concern is that we not discuss it.
> ...

How about removing the part instead?

>>> I've shown a number of examples (just with vCard, even) of real-world 
>>> scenarios that have led me to hold this position; is your disagreement 
>>> on idealogical grounds, or do you have any counter-examples?
>> The fact that some extension mechanisms have failed doesn't prove they 
>> are a bad idea in general. There are many that have worked perfectly 
>> well.
> 
> Could you name some? I'm aware of some that have worked adequately, such 
> as the class="" attribute in HTML, but I think it would be a stretch to 
> say that any Web technology has had non-spec-based extension mechanisms 
> that have worked "perfectly".

Why does it need to be a "Web" technology? Does Atom matter? XHTML? 
XSLT? WebDAV?

> ...
>>>> So *will* you fix it once draft-ietf-vcarddav-vcardrev is approved 
>>>> for publication?
>>> Yes, of course (assuming that the revised draft represents what 
>>> implementations are interested in supporting, anyway -- I guess there 
>>> is the chance that the revised draft is ends up being DOA, though I 
>>> have no reason to believe that will happen in this case).
>> And whether this is the case will be decided by whom?
> 
> Implementors, presumably. Who else can decide whether a spec is adopted?
> ...

Who is going to measure that support and then make a decision for the 
HTML5 spec?

> ...
> Again, I am not editing HTML5 to be what I want it to be, I'm editing it 
> to be the best technical solution that I can find for the problems that 
> people have raised. Despite my personal opinions on the topic, many people 
> do in fact seem to care about these use cases, and so it would be remiss 
> of me to ignore them.
> ...

Right now, you're ignoring those who disagree with the inclusion. How is 
that different?

>>>> The proposal is *not* to make it part of the language. (And, btw, 
>>>> I've seen several other people agreeing with that, favoring a more 
>>>> generic approach instead).
>>> I don't understand how the predefined vocabularies could not be part 
>>> of the language. What do you mean by "part of the language"?
>> Defined by HTML5, or by something it normatively refers to.
> 
> By "part of the language" I mean a feature that HTML authors can use as a 
> first-class feature. We could take the HTML parsing section out of the 
> HTML5 spec, define it in another document, and not explicitly or 
> normatively reference it, but that wouldn't make the syntax stop being 
> part of the HTML language.
 >
> So again, the predefined vocabularies are part of the language. Whether 
> there's an explicit normative reference or an implicit import through a 
> back-reference doesn't seem to matter, except that the former is far 
> clearer to readers.
> ...

It doesn't matter to you, but it does matter to me, because we have a 
different opinion about what defines the language.

So if it doesn't matter to you, why do you insist on that approach?

>>>> BTW, I notice that you didn't reply to:
>>>>
>>>>> But then, it would be a reason to add lots of other things as 
>>>>> well. Some of which being more important, and related to 
>>>>> *existing* interop problems of UAs, btw.
>>> I didn't realise there was anything to respond to. Which other things 
>>> did you have in mind?
>> I was wondering whether anything that is browser related and affects 
>> *existing* implementations, and does have *current* interop problems 
>> merits being addressed by HTML5. In which case I'd like to restart the 
>> discussion of making requirements on the treatment of 
>> Content-Disposition (which currently has little interop with respect to 
>> I18N).
> 
> I'm sure the HTTP working group specs get plenty of review without having 
> to piggy back on the HTML5 spec.

That isn't an HTTP WG spec.

BR, Julian

Received on Friday, 24 July 2009 05:42:27 UTC