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

On Oct 2, 2009, at 4:45 PM, Shelley Powers wrote:

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

It seems to me like Inkscape's main requirements are:

- Their design-time information should be unambiguously parsable from  
the content.
- It should be possible to clearly associate a piece of design-time  
information with a particular element.
- Their design-time information should not ever collide with extended  
information added by other tools.
- Their design-time information should have UA processing requirements  
that lead to it not affecting rendering when deployed.

Is the following a requirement?

- Their design-time information should round-trip through general- 
purpose XML processing tools (or future HTML processing tools).

It seems like the following are *not* requirements:

- Programs other than Inkscape should be able to understand Inkscape's  
annotations.
- Data mining tools should be able to extract Inkscape's annotations  
into a general-purpose data model.


Considering currently existing mechanisms:

- I don't think HTML comments satisfy these requirements, at least if  
round-tripping through other tools is necessary.
- It seems like RDFa could satisfy the use case, though at the cost of  
needless complexity (since RDFa is designed to handle the two non- 
requirements listed above).
- It sounds like a set of data-* attributes with a naming convention  
could pretty much satisfy the use case (data-inkscape-whatever), but  
would violate the spirit of the spec: "These attributes are not  
intended for use by software that is independent of the site that uses  
the attributes", assuming an authoring tool is considered independent  
of the site where content is deployed. Presumably, JavaScript  
libraries are not considered "independent of the site", but I would  
say general-purpose authoring tools are.
- Class values with a naming convention could not fully satisfy the  
use case, because there is no support for key/value pairs.
- "Other applicable specifications" extension would not satisfy the  
use case, because Inkscape does not want to make a public  
specification for their private data.

Regards,
Maciej

Received on Saturday, 3 October 2009 00:37:43 UTC