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

On Oct 5, 2009, at 16:06, Shelley Powers wrote:
>> I see. Are existing JS libraries operating on SVG trees in existing  
>> Web content using namespaced attributes and elements in way that  
>> data-* attributes don't address?
>>
>
> So let me get this straight: you're expecting that when a person  
> copies and pastes a SVG file into HTML5, they will go through the  
> SVG and for every namespaced attribute, they will replace it with a  
> data-* attribute?  And what are they supposed to do with the  
> namespaced elements?
>
> Do I understand you correctly? Is this your proposal?

It's not a proposal. It's a question. The purpose of the question is  
to understand if namespaced attributes have some important technical  
characteristics (when network effects are ignored) that data-*  
attributes don't have.

>>> I tried to explain some uses and interests in distributed  
>>> extensibility above. Let me know if these weren't sufficient.
>>>
>>> I believe that Tony also referenced a view of distributed  
>>> (decentralized) extensibility, as well as some possible use cases.
>>
>> I'm interested in seeing a definition of what "decentralized  
>> extensibility" so that alternative proposals can be tested against  
>> the definition to determine if they constitute "decentralized  
>> extensibility". (I guess it wouldn't be unexpected if you, Tony and  
>> Sam came up with different definitions, although so far Sam seems  
>> to be avoiding writing down a definition even when asked.)
>>
>> Currently, the WG lacks a definition against which to assess if  
>> e.g. the naming scheme Jonas mentioned (<org_example_foo>) would be  
>> "decentralized extensibility".
>
> I believe I have answered the question, and I think others have  
> also. I'm not sure how else to answer it, though, so that it meets  
> your criteria for a definition.

Sorry for appearing dense, but I have missed your answer. Could you  
please point me to it?

>> For clarity, do you mean element and attribute names?
>>
>> Are there any other salient characteristics of "decentralized  
>> extensibility", in your view, than
>> * a diverse audience being able to mint names
>> AND
>> * collision avoidance when the minters are unaware of each other
>> ?
>>
> I think avoidance of name collision is important, particularly if we  
> need to phrase this discussion in terms parser developers can  
> understand. I think parser developers can understand this one.
>
> I think it's also important to facilitate an approach that is based  
> on a mature specification that has widespread use. More importantly,  
> one that could be used in SVG regardless of whether the SVG is  
> parsed as XML, or as part of an HTML document.

So is this the comprehensive list:
* a diverse audience can mint names
AND
* collision avoidance when the minters are unaware of each other
AND
* the mechanism could be applied in SVG regardless of whether the  
underlying parser is an HTML parser or an XML parser
?

For clarity, do you permit the mechanism to require an update to SVG  
specs? That is, could it be an SVG 2.0 feature? Or are you  
constraining the solution to be the one SVG 1.1 already has?

>> I mean that the ability of a user to read HTML5 or SVG content is  
>> not gated by one party. The user's ability to read content in HTML 
>> +FooML (where FooML is an extension) could be gated by one party if  
>> the ability to process FooML is only available from the proprietor  
>> of FooML as a binary extension to those browsers that the  
>> proprietor of FooML chooses to support.
>>
>
> Gated?

Oops. Wrong word there. I have to use the non-native English writer  
excuse.

I meant the ability of one party to be a gatekeeper in the sense of  
granting or withholding the ability to read the extended file format  
in a given computing/browser environment.

> So an application provides several namespaced elements and/or  
> attributes that a person could add to their SVG or HTML, but the  
> application developer's are claiming that the elements and/or  
> attributes are proprietary and can't be processed by anyone else.
>
> So therefore, the use of namespaced elements and/or attributes is  
> invalid?
>
> I would assume, then, that we should pull of the W3C specifications,  
> because there's isn't a single one of them that can't be used to  
> create something proprietary.

It would be naïve to think that declaring proprietary extensions as  
non-conforming prevented proprietary extensions from being launched,  
but going ahead and endorsing a mechanism for proprietary extensions  
probably leads to a proliferation of proprietary extensions, since the  
signal would be that they are OK.

>>>>>> Again, outside of the initial concern about decentralized  
>>>>>> extensibility as a whole.
>>>>
>>>> It depends on whether 'decentralized extensibility' is synonymous  
>>>> with Namespaces.
>>>>
>>>
>>> So, what you're saying, then, is that your concern really isn't  
>>> about distributed/decentralized extensibility. Your concern is  
>>> about the specific implementation. Do I have that right?
>>
>> Assuming that the <org_example_foo> naming convention without API  
>> changes counts as decentralized extensibility, then this particular  
>> concern doesn't apply to decentralized extensibility in general but  
>> to a particular implementation.
>>
>
> I'm confused, sorry. You have said we have not stated what  
> decentralized extensibility is, but then you're saying whatever it  
> is, we can use <org_example_foo> instead.

No. You seemed to suggest that hypothetically there can be non- 
Namespaces "decentralized extensibility". If there weren't, how could  
my concern be with a "particular implementation"? I tried to offer a  
hypothetical that'd address this particular concern.

If you don't allow for the possibility of non-Namespaces language  
features offering "decentralized extensibility", saying that my  
concern is with a particular implementation doesn't really make sense.  
Scoping my concern to a particular implementation only makes sense if  
you accept the possibility of other implementations.

> It seems to me, then, that you do understand what we mean by  
> decentralized extensibility, and your requests for clarification in  
> this regard are, sorry to be so frank, disingenuous.

Maybe I understand what *you* mean. If so, great! However, you haven't  
exactly made it easy to confirm if you and I have the same notion of  
what "decentralized extensibility" might mean.

I think it would be prudent not to jump to the conclusion that I also  
understand what Sam means or what Sam's goals are in inviting a  
"decentralized extensibility" proposal from Microsoft.

> So your counter proposal is, then, that people just make up whatever  
> elements, without namespaces, and incorporate reverse DNS into them,  
> as a way of handling name collision?

It's not a proposal. It's a hypothetical construct for the purpose of  
understanding what characteristics of "decentralized extensibility"  
are essential and what are incidental features of Namespaces.

> Frankly, I'm disappointed at the suggestion of a proposal that  
> creates such a divergence from what's been practiced, and promoted,  
> in the past from the W3C.

So is "decentralized extensibility" constrained to be exactly  
Namespaces or isn't it?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 5 October 2009 15:12:39 UTC