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

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


>>> >     * A browser wants to allow custom behaviors to be defined in 
>>> one  > module and attached automatically to custom elements.
>>>
>>> How would the custom behaviors be implemented? In page-supplied 
>>> XBL2?  In native code specific to a combination of browser, OS and 
>>> CPU  architecture pre-installed prior to loading the page?
>>>
>>> If in XBL2, wouldn't it be sufficient to be able to bind the 
>>> behavior  to class attributes or to local names that have a special 
>>> character  reserved for extensibility (such as '.' or '_' but *not* 
>>> ':') without  having to go through the trouble of changing the 
>>> namespace URI from  what the HTML5 spec says now?
>>>
>>> If in native code, how would the unavailability of the native code  
>>> behavior for a given browser, OS and CPU combination be less bad 
>>> for  the ability of the user to read Web content than the 
>>> unavailability of  an NPAPI plug-in (or NPAPI-plug-in-like ActiveX 
>>> control)? That is, how  would this proposal be an improvement over 
>>> the current mechanism for  proprietary extensions?
>>>
>>> (I think the discussion about extensibility should framed in terms 
>>> of  the ability of users to read content. Not in terms of the 
>>> ability of  authors to write content.)
>>>
>>
>> I don't think it's appropriate to continue to re-frame these 
>> discussions. It's just as viable to discuss extensibility in terms of 
>> authoring content, as it is to discuss extensibility in terms of 
>> consuming.
>
> 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.

That's incredibly frustrating, because I see nothing that produces, 
let's say, Microdata, or consumes it, other than some play applications. 
Yet you don't demand the same level of rigor with it.

So yes, I do push back at your arguments, because you apply them 
unevenly Henri.

>> Is your main concern, and reason for re-framing this discussion in 
>> terms of consumers because of your concern about automated processes 
>> to read this data?
>
> No. My main concern is Web users (people using a browser) on platforms 
> other than the couple of usual ones being able to read content.
>
> HTML already have a point for proprietary extensibility: 
> <embed>/<object> causing an NPAPI plug-in (or an ActiveX control with 
> similar capabilities) to be instantiated *where available*. The most 
> common application of this extension point has been extending HTML 
> with Flash without the "centralization" of the W3C. 
> There's a non-trivial amount of content out there that is not readable 
> without the Flash Player plug-in. When a user is using a 
> browser/OS/CPU combination for which the Flash Player plug-in is not 
> available, the user is locked out of reading the content expressed 
> using the Flash extension. Sometimes there's content in there that is 
> very relevant to what the user is trying to do. (Users who need 
> Assistive Technology are locked out unless an accessibility-enabled 
> version of Flash Player is available for their browser/OS/CPU 
> combination.)
>
> Previously, this affected e.g. users of 64-bit Linux. Now Flash is 
> available for 64-bit Linux, but the issue still affects e.g. S60 users 
> (like me). (The "mobile" Flash Player is useless for accessing Flash 
> content as actually published on sites whose authors were testing on 
> desktops.)
>
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.

> (HTML and SVG are different, because implementations are available 
> from multiple vendors and Gecko and WebKit are open for porting 
> without the participation of a particular vendor, so even if someone 
> refuses to port an implementation of the Open Web Platform to a 
> particular computing platform an interested party can do so on their 
> own initiative. I have 5 browsers on my S60 phone. 3 self-contained 
> browsers and 2 thin clients for server-side browser engines.)
>
> Now, if "decentralized extensibility" is meant to enable processing of 
> subtrees using binary plug-ins whose availability may be blocked on 
> the computing platform of your choice even if you were volunteering to 
> port the plug-in yourself, how are things improved from the user point 
> of view compared to <embed>/<object> which we already have?
>

I'm sorry, but I don't understand what you're saying here. Could you 
rephrase it?

>> I don't understand this fixation on taking what we know works--we 
>> _know_ works, we have evidence, it exists, it is neither speculative, 
>> nor theory--and replacing it with something untested and untried.
>
> See Philip's emails in this thread. The proposal is *not* what has 
> been tested and tried in IE.
>
But the concept of namespaces has been tested and tried in many other 
applications and browsers.

Microsoft has stated, in its proposal, what it, the company is willing 
to do to meet the needs of this proposal in IE. It wasn't just a 
proposal, it was a commitment by one of the major vendors. Frankly, that 
counts for a lot because one issue with the current state of 
extensibility on the web has been lack of implementation by one of the 
major players. That major player is willing now, to make a commitment to 
this extensibility. Frankly, I'm pleased as punch, sorry that you're 
less so.

As for the concerns about existing applications, the company 
representative has already addressed issues about its current 
implementation[1].

> As for Namespaces being tested and tried, they have been tested and 
> tried, and they've turned out to be bad:
>
http://wiki.whatwg.org/wiki/Namespace_confusion

I think that's a useful page to have, to ensure that our use of 
namespaces perhaps avoids at least some of the problems. If not through 
the specification, through education and outreach. But I balance that 
page with the sheer volume of web resources that exist on the web, 
today, that have implemented namespaces correctly, and usefully.

One can find bad uses of anything. I'm sure in a few years, we're going 
to see some pretty horrendous uses of dt/dd, not to mention 
article/section.

And if we tried to create something new, some version of dot-based, 
reverse DNS, CSS pseudo like thing, we'd probably have the same number 
of problems, but with many fewer positive implementations.

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.

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

Shelley

[1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0034.html

Received on Friday, 2 October 2009 12:55:42 UTC