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 18:45:36 -0500
Message-ID: <4AC690A0.6020201@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:
> 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.

I can't speak for HTML editors, since I don't use any. Perhaps someone 
else who uses such editors can answer this.

I can speak for an SVG editor, Inkscape, which uses namespaced elements 
and attributes to record information about the SVG it produces. And 
before you mention using HTML comments, you should spend time with an 
Inkscape SVG file, to see how extensive the use of namespaced elements 
and attributes are in an Inkscape managed SVG file.

I'm also aware of other applications that have defined attributes to be 
applied to HTML elements so that JavaScript libraries can do something 
with the data. A case in point is a accordion JS application that would 
depend on these attributes. To use the application, I had to add these 
attributes to the div elements that formed the accordion panels and 
header bar.

Now, the HTML5 custom data  could be useful for something like this, 
except for a problem: According to the HTML5 Specification, "These 
attributes are not intended for use by software that is independent of 
the site that uses the attributes."

Probably the reason why is there is nothing in data-* to handle name 
collision. After all, there's only so many types of words to use, and 
there could very well be collision between a JavaScript library that 
does an accordion, and perhaps another one that does a tabbed UI, and 
both are used in the same site.

Perhaps the HTML5 author meant these were meant to be used in scripts at 
one's site, but there's still no mechanism for handling name collision. 
Frankly, custom data-* attributes are kind of a non-starter.

Using RDFa for these purposes would be inappropriate because that's not 
the underlying purpose for RDFa.

An extensibility mechanism that is decentralized would be appropriate, 
because such a mechanism would have, built in, the capability of dealing 
with name collision. That means JS library 1 could define it's own 
"js-tab" attribute, and JS library 2, could define its own "js-tab2" 
attribute, and a person could use both libraries without a problem.

Now, I suppose one could use the class attribute, but there are going to 
be instances where one needs beyond just a simple attribute. There may 
be times when an entire element is needed, and class, id, data-*, just 
aren't going to hack it.
>
>> 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"?

First, a caveat: I'm answering only for myself, not for any of the RDFa 
folks, who may have a different, and more accurate, take.

In my opinion, RDFa is a decentralized extensibility, yes, but with a 
limiting constraint: the data that is recorded using RDFa is based on a 
specific model, RDF. As such, it's extensible, in that many data 
vocabularies can be defined within RDF, and recorded with RDFa. It's 
extensible in the same way that the SQL data model is extensible. Like 
RDF, the SQL model is decentralized, too, in that you don't have to go 
to some governing body in order to define a new use for SQL. Wordpress 
has its own database design that differs from Drupal's, but both are 
based on the SQL Data model.  The same applies to RDF: you have FOAF, 
you have the older RSS 1.0, DC, and so on -- these are all vocabularies 
that have either been ported to a RDF vocabulary, or were based in RDF 
from the beginning.

So yes, RDFa, is extensible, but there is a perimeter around the usage, 
and that is the underlying model. Makes for reusable tools and 
technologies, and simplifies merging of data, but is not an _generic_ 
decentralized extensibility. For instance, RDFa is great for recording 
Creative Commons information, and that CC information can be accessed by 
tools and used to build a database of CC licensed content that exists, 
globally, across the web. However, RDFa would not be useful, or I should 
say, would be overkill for something like Inkscape, which wants to 
record a significant amount of information within a SVG document, in 
order to open that document in it's own tools to a previously saved state.

This information is generated by Inkscape, and used by Inkscape. Other 
tools could use it if they want,  but Inkscape doesn't care about the 
data being used within a wider data collection: it just wants to 
annotate the SVG that it generates.

Inkscape can extend SVG in this way, because there are extensibility 
mechanisms incorporated into the spec, and the underlying specification 
markup. When SVG was first defined, the spec writers didn't have to say, 
"Oh, well, tools will need to record information into an SVG drawing, so 
we need to define, right now, fields and attributes specific to tools 
that will generate SVG." If this was the way that SVG had to be defined, 
the SVG spec writers would have to guess about all the various uses of 
SVG, and try to ensure that fields and attributes and what not were 
included for those uses, and so on.

SVG is not a small specification. I can't imagine how much larger it 
would have been if every possible need was defined ahead of time and 
built into the specification.

I'm overlong in answering, but I'm trying to be as complete as possible.
>
>>>> 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.
>

I'm sure that when Tony returns from vacation, he'll give you an answer.

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

You're talking about the additional functionality necessary in order to 
parse the namespaced elements in HTML, and attributes, and store them in 
the DOM? We're not talking about XHTML, I'm assuming, since this 
capability already exists. You're talking about the proposal and its 
impact on the parsing, and JS access, in HTML?




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

I think you misunderstood my answer. And I'm not quite sure if your 
understanding of "centralization" is the same as mine, either, from how 
you're using it in the above sentence.

I wasn't talking about SVG as an extension to HTML. I was talking about 
SVG being part of HTML, and the fact that it's fairly common for 
namespaced elements and attributes to be used in SVG. Common, and 
permissible based on the SVG specification.

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

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


Being able to handle name collision is probably the biggest area of 
concern.

Any form of extensibility has to be able to handle a wide, diverse 
audience, who may or may not be aware of the work others are doing when 
they take advantage of the extensibility.

Yes, namespaces do work in this regard, and have worked in this regard 
in the past.

Another reason to consider using namespaces is the fact that the use of 
namespaces could extend beyond just HTML5--being used in past 
specifications, as well as current ones, such as SVG. Anything defined 
in HTML5 would only be usable in HTML5. That's not particularly efficient.

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

You really misunderstood me on this one. I think it's the different 
views we each have.

By this I meant that there are elements of HTML5 that are not currently 
supported in any browser, and won't be available in all environments for 
potentially years in the future.

I can see now you must have meant something about royalty or patents? Is 
that it? I'm not sure where you're coming from with this one, based on 
your most recent answer.

>>> * 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.
>
No, I don't believe that decentralized, or distributed, extensibility 
has been defined as another name for 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.
>

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?

I'm still having a hard time understanding what your specific concerns 
are. It seems one moment that you're concerned about Microsoft's 
specific proposal, the next, issues to do with namespaces, and then it 
jumps to the highest level: you're concerned about distributed 
extensibility, generally. I feel like I'm aiming at a moving target.

Again, though, we are looking at this issue with two different 
viewpoints. Perhaps that explains the disconnect. Hopefully others will 
jump in and provide you the answers I don't seem to be able to provide. 
I do feel you deserve answers to your questions.


Shelley
Received on Friday, 2 October 2009 23:51:23 UTC

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