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

On Oct 2, 2009, at 19:41, Shelley Powers wrote:

> Henri Sivonen wrote:
>>
>>>>
>>>> It seems to me this needs to be assessed in the context of use  
>>>> cases. It would help to know what kind of state editor vendors  
>>>> would like to save, what mechanisms they use now and what state  
>>>> saving they recall they have foregone due to lack of syntax in  
>>>> HTML.
>>>>
>>> A use case was provided. I added to it. If you don't find it  
>>> sufficient, feel free to reject.
>>
>> A general class of use cases was provided but no concrete cases  
>> that'd allow solutions to be evaluated.
>
> What do you mean by "concrete"?

A specific example of what kind of state an HTML editor tool wants to  
save.

> No, I didn't say that RDFa is a decentralized extensibility, by  
> itself.

OK. For clarity, are you saying that RDFa *isn't* "a decentralized  
extensibility"?

>>> And that is a good form of openness, though as you say, not  
>>> without its own challenges. But, that's more of a application  
>>> extensibility rather than a markup extensibility. Yes, HTML has  
>>> object, but that's so browsers could be extended with additional  
>>> functionality.
>>>
>>> This proposal is talking about extensibility at the core level, in  
>>> the markup, itself.
>>>
>>> Frankly, two different things.
>> [...]
>>> I'm sorry, but I don't understand what you're saying here. Could  
>>> you rephrase it?
>>
>> How is an ActiveX control that hooks to <object> and a byte stream  
>> different *from the user point of view* than an ActiveX control  
>> that hooks into "custom tags" in IE? In both cases, there's content  
>> out there that you can't read in your browser without installing an  
>> additional piece of software, and the piece of software isn't  
>> available for all browsers on all platforms.
>
> Henri, sorry, I'm probably being particularly dense today, but I'm  
> not sure how this is related to the Microsoft proposal.

IE today allows ActiveX controls implement rendering of "custom tag"  
subtrees. I'm interested in understanding the relationship of that  
feature to the proposal.

>> How does the Web become better if additional pieces of native-code  
>> software hook to the DOM in addition to hooking to <object>/<embed>  
>> and a byte stream?
>>
> Native code software?

Code implemented as instructions native to the CPU. The way NPAPI plug- 
ins and ActiveX controls are implemented.

> Well, when it comes to namespaced elements in SVG in an HTML  
> document, I can see immediate benefit to JS libraries accessing  
> those elements.

SVG is not a "decentralized" extension to HTML, AFAICT. It's  
centralized right here at the W3C together with HTML.

> So, let's ignore the implementation details and focus on your  
> concerns about decentralized extensibility. Is your concern, then,  
> that no one has provided an argument you can agree with that  
> decentralized extensibility is needed? You did question Tony's  
> proposal, but I didn't see you question the assertions in the  
> proposal about the need for extensibility, only specific use cases.  
> What exactly do you have against decentralized extensibility? If you  
> can list out the specifics, perhaps we could discuss them, one by one.

I can't agree or disagree on whether 'decentralized extensibility' is  
needed and I can't say what I have (if anything) against it without  
knowing what 'decentralized extensibility' is. It would be helpful to  
have a necessary and sufficient definition of what language  
characteristics constitute 'decentralized extensibility'.

Is the set of characteristics a proper subset of the characteristics  
of Namespaces in XML or are the sets one and the same?

>> * When content depends on language extensions that need client  
>> software extensions to process, the ability of users to read Web  
>> content is harmed in software/hardware environments for which the  
>> client software extensions aren't available.
>>
>
> I would say that a significant proportion of HTML5 falls into the  
> category of needing implementation that isn't universally available  
> in all environments.

As far as I know, the HTML5 spec is royalty-free and it's being  
implemented in multiple engines some of which are Open Source. There  
doesn't seem to be any one party controlling the availability of an  
HTML5 implementation for a given computing platform.

>> * Working with string tuple identifiers is harder than working with  
>> simple string identifiers.
>
> Again, this has nothing to do with your concern about decentralized  
> extensibility. I think we should focus on the most significant  
> concern, address it, and then move on to implementation once past  
> that initial concern. Don't you think?

It depends on whether 'decentralized extensibility' is synonymous with  
Namespaces.

>> * Prefix-based indirection (where the prefix expands to something  
>> as opposed to being just a naming convention) confuses people.
>>
> Again, outside of the initial concern about decentralized  
> extensibility as a whole.

It depends on whether 'decentralized extensibility' is synonymous with  
Namespaces.

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

Received on Friday, 2 October 2009 17:41:46 UTC