Re: "wrapper format" (was: restarting discussion)

On Sat, Jul 4, 2009 at 6:25 AM, Dave Crossland <dave@lab6.com> wrote:

> 2009/7/1 Christopher Fynn <cfynn@gmx.net>:
> > Why do we need another "wrapper format" to contain font + meta-data??
>
> Because the need for better metadata is required by various files
> found on the web, not just fonts; but fonts prompt a solution since
> they are new to the web. http://noeot.com/mame.html explains in more
> detail.
>

I am deeply skeptical of this approach. The use cases are not compelling,
the need for a new format is not justified, and specific technical details
are broken and clearly have not been tested at all.

The use cases are not compelling. Take for example this paragraph of
http://noeot.com/notices.html:

> For example, consider an HTML page which links to a CSS style sheet. Our
> proposal allows the CSS style sheet *author* to attach user-oriented
> meta-data which user agents (e.g. browsers) *should* normally display. Our
> proposal allows the origin server and any proxies providing the CSS to
> provide additional meta-data. One use case: a CSS author could attach a
> copyright declaration and license information as meta-data to a CSS program.
> That meta-data would be available to users from pages which link to that
> style sheet.


I assure you that almost no users care about such metadata, and therefore
browsers will not "normally display" it. At best it might be visible in a
Page Info window or somesuch. The trend in browsers and user interfaces is
to display only what is immediately relevant to the user. Metadata isn't.

Simultaneously, the operator of a server offering CSS or proxying could
> attach meta-data announcing that due to a planned outage the resource will
> not be available next Thursday between noon and 3PM, PST.
>

I hope I don't have to explain how absurd this is.

Every file format used on the Web today is extensible enough to support
inclusion of arbitrary metadata that will not disrupt existing Web browsers.
http://noeot.com/notices.html tries to motivate the need for a universal
wrapper format, saying
>
> This is a disasterous approach for it implies that if we have N file
> formats (or "resource representation formats" in W3C-speak) that we must
> have N standards efforts to add meta-data support.


Libraries for reading and writing all the commonly used formats already
exist. Gluing them together is not a lot of work compared to designing,
evangelizing and deploying a totally new format.

It implies that a conforming web tool must have N separate libraries, one
> each to understand each format.


A tool that processes a format already has libraries to understand that
format.

It implies that consensus about the form meta-data should take is difficult
> to arrive at because any concessions by stake-holders to adjust their own
> formats can come only at the expense of revising their existing standards.


Untrue. Registering new chunk types is generally not strenuous.

There aren't many technical details here, but proposal for extending HTML is
deeply flawed. In particular there's a proposal for including notices in the
HTML <head> element like so:
<head><notice>Notice</notice></head>
In Firefox, Safari and HTML5 the parser moves the <notice> into the <body>
so it's rendered at the top of the page. Even worse, adding metadata to
links is supposed to work like this:
<head><link><acknowledge>Acknowledgement</acknowledge></link></head>
But <link> is a leaf element, so in the DOM the <acknowledge> element is not
a child of the <link>. And HTML parsers move it into the <body> too. Minimal
testing would have uncovered these problems, which undermines my confidence
in the rest of the proposal.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Received on Saturday, 4 July 2009 02:16:15 UTC