Re: ISSUE-41/ACTION-97 decentralized-extensibility

Shelley Powers On 09-10-19 13.59:

> On Sun, Oct 18, 2009 at 7:34 PM, Aryeh Gregor wrote:
>> On Sun, Oct 18, 2009 at 7:24 PM, Leif Halvard Silli:


[...]

>>> RDFa is an example of centralized extensibility.
>> Correct.
> 
> I don't agree, but regardless of opinion in this regard, neither
> centralized extensibility nor RDFa is germane to the discussion.

Its use is decentralized. But what makes its use valid in HTML is 
the HTML+RDFa document, which is a centrally decided extension of 
the HTML spec. (Kind of illogical ... We do not have namespaces in 
HTML yet. But we can add a namespace based solution such as RDFa 
by writing another spec ...)

The debate about decentralized extensibility is about a centrally 
decided extension method for adding decentral extensions.

>>> A class "foo" might be used in all elements, irrespective of which namespace
>>> the elements belong to. With namespace support, you would thus be able to
>>> select a subclass of all the elements with class name "foo" - e.g. you could
>>> select only those "foo" class elements that belong to the namespace "bar".
>> Using a class "bar" instead of a namespace "bar", and
>> querySelectorAll('.foo.bar'), is just as easy.  It also works right
>> now (at least if you use a JS library to mimic querySelectorAll()).
>> It doesn't guarantee uniqueness of the class name, of course, but how
>> essential that is seems to be a matter of debate.
>>
> 
> I would say since the topic is related to decentralized/distributed
> extensibility, the prevention of name clashes is entirely germane to
> the discussion.


Indeed.

 

>>> We are discussing what /should/ be considered "standard" here.
>> Well, the word "standard" has a common English meaning, as well as a
>> conventional technical meaning within the W3C, IETF, and similar
>> bodies.  Content whose format is not publicly specified and which can
>> only be processed using proprietary tools from a single vendor is not
>> standard no matter who says otherwise.
>>
> 
> I'm not sure where the concept of proprietary tools enters this. I
> have seen HTML used for proprietary tools, and CSS, too -- should we
> then desist in working on these? Or should we accept, as fact, that
> any open specification can be, and will be used, in proprietary tools.
> 
> And again, I'm not sure how anything that will be added to HTML pages
> cannot be public specified. We can have a standard form of
> decentralized extensibility, in fact we do, and have for over a
> decade: namespaces. How this is used by any one vendor is not our
> concern, other than the use has to be valid if they want the use to
> validate.
> 
> We're not nannies to dictate what every company and vendor does with
> these specifications. To say that, "We're sorry but you're using HTML
> for a proprietary tool and that's not 'standard'", when it is
> perfectly acceptable.
> 
> Unless we're willing to tell every maker of a commercial product that
> uses HTML, or CSS, or any number of W3C and other specifications that
> they have to desist, I think we need to separate our concerns on this
> issue from the core of the discussion.


+1

 
>>> So you *support* namespaces in HTML 5, you just do not think that they
>>> should be considered valid?
>> I definitely think it makes sense that the spec should make anything
>> unstandardized invalid.  I'm not sure whether HTML5 needs to specify
>> what invalid mechanism you should use if you want to extend the
>> language in a non-standard way.
>>
> 
> That's a risky path to walk. You've just equated proprietary with
> standard, and then stated non-standard should be invalid. Are you
> saying that all proprietary uses of HTML5, then, should be invalid?

+1

-- 
leif halvard silli

Received on Monday, 19 October 2009 13:23:50 UTC