Re: Decentralised extensibility idea (ISSUE-41)

Philip Jägenstedt, Fri, 15 Jan 2010 10:06:19 +0100:
> On Fri, 15 Jan 2010 00:30:21 +0100, Toby Inkster wrote:
> 
>> This is a sketch of a proposal for decentralised extensibility (DE) in
>> HTML5. If there is interest in it, I'll be happy to write it up as a
>> change proposal, but I'd like to see what people think first.
> 
> I like the overall goal, because it is exactly like microdata. 

It is perhaps even closer to microformats = HTML4 profiles.

So, if it is true that it is "exactly like microdata", then isn't it 
ironic that microdata probably would have had bigger chance of becoming 
a success (= been part of HTML5) if it had been designed around 
@profile instead of reinventing a wheel? (Toby is not the first to 
suggest to allow @profile on any element.)

And why, at all, obsolete @profile if the approaches are so similar? 
Where is the sense?

> Comments below.
> 
>> The class attribute has traditionally been used mostly by authors for
>> their own purposes. That doesn't need to conflict with this solution, as
>> I will later indicate a mechanism for documents to specify which
>> otherspec(s) they are making use of.
> 
> Overloading the class attribute (like microformats) isn't a very good 
> idea, it *will* clash with existing markup. The world doesn't end, 
> but it's best to avoid, and in fact easy to avoid.

It is not clear to me if by "easy to avoid" you meant "easy for authors 
to avoid" or "easy for Toby to design DE so that the problem is 
avoided".
 
>> So, how should one add custom attributes to otherspecs. We repurpose the
>> data-* attributes:
>> 
>>  <span class="Car" data-engine-size="1.8L"
>>   data-colour="blue">Mazda</span>
> 
> What if the original markup were 
> <tr><td>Mazda</td><td>1.8L</td><td>blue</td></tr> or any other form 
> where the data being marked up is visible in the page?

Perhaps there could simply be a free choice between using e.g. "colour" 
as attribute or as class element:

<tr class="Car">
  <td class="brand">Mazda</td>
  <td class="engine-size">1.8L</td>
  <td class="color">blue</td></tr>

>> Currently the data-* attributes are reserved entirely for the author's
>> private use. In this proposal, the definition of those attributes would
>> be changed to allow otherspecs to assign particular meaning to data-*
>> attributes, but only in the case where document authors have explicitly
>> indicated which otherspec(s) they're making use of.
> 
> I don't think this is a very good idea, as data-* are always hidden 
> and not suitable for marking up content that is visible in the page.

What you say here only describes a general feature/issue when data is 
kept inside attributes. (When I first read what you said here, then I 
thought you spoke about a particular problem with @data-*.)

>> So, my original XML-style <car/> element could be written as:
>> 
>>  <span
>>   profile="http://example.com/CarML/html5"
>>   class="Car"
>>   data-engine-size="1.8L"
>>   data-colour="blue">Mazda</span>
> 
> <span itemscope itemtype="http://example.com/CarML/html5#Car">
> <span hidden itemprop="engine-size">1.8L</span>
> <span hidden itemprop="colour">blue</span>
> Mazda
> </span>

So, in a summary, the different approaches are that DE only points to a 
spec. Whereas MD points to an item in a glossary. (Markup language 
verus glossary language.) And thus MD also avoids clashes.  However, I 
wonder, if not many authors in practise would not also add the "Car" 
class? :

<span class=Car itemscope itemtype=http://example.com/CarML/html5#Car>

And, w.r.t. DE, then Toby has not said that pointing to #Car could not 
be possible ... ?

<span class="Car" profile="http://example.com/CarML/html5#Car">

By the way: that DE doesn't require you to point to the profile URI 
every time you use the "Car" class is of course also meant to be a 
feature! On an edge, DE is for designing a "markup language" - it isn't 
only for meta data. ;-)
 
> Of course your example and mine would be much better if the engine 
> size and color were actually part of the page, e.g.
> 
> <tr itemscope itemtype="http://example.com/CarML/html5#Car">
>   <td itemprop="manufacturer>Mazda</td>
>   <td itemprop="engine-size">1.8L</td>
>   <td itemprop="colour">blue</td>
> </tr>
> 
>> An optional extra would be a DOM method
>> getElementsByClassNameWithProfile(classname, profileuri) which return a
>> collection of elements matching the provided class, but only if they
>> were within the scope of a particular profile URI.
> 
> Microdata: document.getItems("http://example.com/CarML/html5#Car")

So, quite similar. But here we also see that MD is more freeform than 
DE: In DE, if you use the "Car" class, then it doesn't have any effect, 
unless it is in scope of the profile URI. Whereas in MD, you must 
always use itemtype="http://example.com/CarML/html5#Car" - and thus you 
can place it wherever you wish.

> As a side note, I'm not sure what kind of page one would find at 
> http://example.com/CarML/html5 in your example, but what is possibly 
> missing from microdata is some formal way of describing the 
> vocabulary to automate validation. I think it's premature to 
> standardize anything though, experimentation is necessary.

Since a microdata itemtype is identified with a fragment URI, the need 
for a vocabulary specification spec might not be pressing. It would 
probably be good if DE specs also identified each element with a 
fragment URI.
-- 
leif halvard silli

Received on Friday, 15 January 2010 16:29:58 UTC