W3C home > Mailing lists > Public > public-html@w3.org > October 2009

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

From: Shelley Powers <shelleyp@burningbird.net>
Date: Fri, 02 Oct 2009 11:41:33 -0500
Message-ID: <4AC62D3D.4020808@burningbird.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: "public-html@w3.org WG" <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
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 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.

I would think, though, that a standard approach would be better than a 
non-standard approach, but opinions may differ.

>>> 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*.)
>
Sorry, I meant to say Drupal is a producer. Typo.

> 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?
>
No, I didn't say that RDFa is a decentralized extensibility, by itself. 
I you read this, I must not have been clear in my writing.

I was using RDFa and Drupal as a demonstration of this particular argument.

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

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

I'm assuming by this you mean the fact that this proposal modifies how 
namespaced elements are loaded into the DOM, and how will this make 
things better.

Well, when it comes to namespaced elements in SVG in an HTML document, I 
can see immediate benefit to JS libraries accessing those elements. In 
fact, the Microsoft proposal actually answers a concern of yours that 
you've expressed in several different emails (sorry, I don't have them 
to hand) about how namespaced elements and attributes are handled 
differently in DOM when the page is served as HTML as compared to XHTML.


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

Perhaps the real issue is we're not all speaking the same "language", 
and I don't mean English or otherwise. You're seeing the proposal from 
one view, I'm seeing it from another, and we haven't established a 
common communication means to express ourselves to one another.

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

Actually, I don't think you can have an "unfocused" concern. From this 
paragraph, my take is that you don't agree that there is a need for 
decentralized extensibility. I think it's important to focus on the most 
general concern, because if we can't answer that, then I don't known how 
we can defend a specific implementation for decentralized extensibility. 
And if you don't agree with decentralized extensibility, I'm not sure 
why you would propose alternatives, either.

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 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.
>
Forgive me Henri, but the use of terms such as "worthwhile" make it 
extremely difficult to have a useful discussion. What's "worthwhile" is 
so very subjective.

After all, I've seen people (not you) express concerns about 
accessibility measures being "worthwhile" because HTML5 should focus on 
majority needs, rather than minority interests. The minority interests 
may not seem "worthwhile" to the majority.

It's a loaded term.



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


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

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

And to be honest, I don't know how people can use CSS if they're so 
easily confused over prefixes. However, that's an implementation issue, 
and we still haven't resolved your higher level concerns.

>  * 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.
>
Again, that's more of an implementation detail, and we still have higher 
level concerns we should address first, before focusing down into 
implementation.

If we don't address the higher level concerns, then no matter what we 
answer about implementation, we'll never satisfy your concerns. You'll 
never be happy with the answers about the details, because you don't 
like the entire concept.

That's not to say others can't step in, and I hope they do. I just 
happen to believe we should address the highest level concerns, first.

Shelley
Received on Friday, 2 October 2009 16:42:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC