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

On Oct 2, 2009, at 15:55, Shelley Powers wrote:

> Henri Sivonen wrote:
>> On Oct 2, 2009, at 00:22, Shelley Powers wrote:
>>
>>>> Humans who write HTML save their mental state in HTML by writing  
>>>> HTML  comments. Is there a reason why comments with a product- 
>>>> specific  internal formatting wouldn't be an appropriate way to  
>>>> serialize  authoring tool state?
>>>>
>>>
>>> Yes, but comments in HTML are generally meant to be consumed by  
>>> humans, they're not necessarily machine friendly. Being able to  
>>> use formal markup to annotate the text so that it can be returned  
>>> to a specific state in an editor is not an unconceivable need. And  
>>> a need that wouldn't necessarily be met by HTML comments.
>>
>> 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.

>>>> >     * A JavaScript library processes custom tags in a browser  
>>>> and  > turns them into custom controls dynamically on the page.
>>>>
>>>> HTML5 addresses this use case with the data-* attributes. You  
>>>> take the  element that gives the best fallback behavior when the  
>>>> script doesn't  run and then put the script-sensitive stuff in  
>>>> data-* attributes.
>>>>
>>> Now, extend this concept to custom tags that can be turned into  
>>> custom controls AND which can also be extracted by a web bot or  
>>> other external service, in order to combine with like data for  
>>> additional purposes.
>>
>> If you want the markup to be sensitive to bots, too, it looks like  
>> an interop requirement to me and, thus, a case for standardization  
>> rather than unilateral extensibility.
>
> It's a good thing, then, that the concept of namespaces is so well  
> known, widely implemented, and documented in an existing and mature  
> specification, isn't it?

I don't think think the conclusion of using Namespaces flows from the  
need of stardardization.

>> Discussing it only from the authoring point of view is viable only  
>> in a write-only world. In a world where HTML is supposed to enable  
>> communication, the reader side should be considered as well. I my  
>> assessment, considering the reader side is almost systematically  
>> neglected when proposals for "distributed/decentralized  
>> extensibility" have been put forward.
>>
> This is not true.
>
> When we say that Drupal is implementing RDFa in version 7, you note  
> that it's  only a consumer and seem to imply it doesn't count. As  
> for "consumer", there are sites that gather RDFa data, there are  
> plenty of tools that can gather RDFa, so there are consuming tools  
> and technologies. But that never seems to be sufficient. We must  
> come up with Drupal 7, and then we must come up with the Drupal 7  
> RDFa Consumer Application, otherwise it's not justified.

How does Drupal consume RDFa? (When I may have appeared to discount  
the significance of Drupal, I have thought it was an RDFa *producer*.)

Since you bring up RDFa, are you suggesting that RDFa constitutes  
"decentralized extensibility"? If RDFa already constitutes  
"decentralized extensibility", why is namespacing element and  
attribute names needed as well?

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

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?

(Assuming, of course, that that's one of the goals of "decentralized  
extensibility". I asked if it is. It seemed like a plausible goal  
considering what facilities IE provides now for <foo:bar> markup  
patterns. It isn't clear to me what the goals are. It's quite possible  
that you, Sam and Microsoft have different goals.)

> Henri, your concerns tend to be a little unfocused. One moment,  
> you're against extensibility, but the next, you're proposing a new  
> form of extensibility. It's difficult to respond when I'm not quite  
> sure what your concerns are.

My concerns are unfocused, because it's unclear to me what problems  
"decentralized extensibility" is meant to solve and why those problems  
are considered worth solving. Also, it is unclear to me what the  
salient characteristics of "decentralized extensibility" are and if it  
is possible to have "decentralized extensibility" that doesn't involve  
colons or the string "xmlns". That is, it's unclear if "decentralized  
extensibility" is truly an independent set of characteristics that  
Namespaces happen to satisfy or if it is a synonym for Namespaces.

> So, is your main concern against any form of extensibility? Or is it  
> the use of namespaces? What is your primary concern?


I have several concerns. I don't want to elevate any one of them as  
primary.

  * I think we should fit solutions to worthwhile problems rather than  
look for problems that fit particular solutions.

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

  * Working with string tuple identifiers is harder than working with  
simple string identifiers.

  * Prefix-based indirection (where the prefix expands to something as  
opposed to being just a naming convention) confuses people.

  * Changing how markup corresponds to the localName DOM property may  
have compatibility problems with existing content unless Selector  
engines are changed in ways that violate assumptions made in the  
design of Selector engines. I would assume that it's non-controversial  
that changes that require changes to Selector engines would be bad.

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

Received on Friday, 2 October 2009 14:52:43 UTC