RE: WOFF and extended metadata

> From: Tal Leming [mailto:tal@typesupply.com]
> Sent: Thursday, May 27, 2010 9:13 AM
> To: Sylvain Galineau
> Cc: Jonathan Kew; Vladimir Levantovsky; Christopher Slye; www-
> font@w3.org; public-webfonts-wg@w3.org
> Subject: Re: WOFF and extended metadata
> 
> 
> 1. Establish a metadata-extension structure. Define what UAs would do
> with unknown elements outside of that structure.
> 
> My concern with this is that it draws a line between "in the spec" and
> "not in the spec." It seems that you would have to define the spec in
> your code to filter out unknown elements that occur outside of the
> metadata-extension boundaries. When metadata version 5.0 comes out, you
> would have to update your code to know about the new additions to the
> spec. That doesn't seem to fit your "write it once and never have to
> worry about it again" comment from yesterday. Or, maybe I am missing
> something?

I'm not sure what you're saying. My proposal defines everything that a
browser will render, including an extension point allowing font vendors
to add their own data to the font info UI. Once I have written rendering
code for such a format, I *am* done. The metadata we have already defined 
will render. The  conforming metadata you and others add will render too. 
All of it. It will work the same in 10 years as it would next week.

As for unknown XML, I can't prevent it, and vendors may even want to
include things they don't need browsers to render. As rendering that
would be entirely optional, I don't need to worry about it either.

Thus instead of limiting the metadata to what we've defined and making 
anything else optional, I'm trying to cover 90% of what's going to be 
needed in practice at the lowest possible cost for everyone. I am also 
trying to reduce the odds that we need to rev this schema anytime soon, 
most likely to add simple sets of properties that can be mapped to 
name-value pairs. That would be a waste of our collective time, imo.


> 2. Establish a some restrictions that govern the structure of the
> metadata in general. (Nesting, lang attribute, etc.) State that
> extensions are allowed and extensions that follow the structural rules
> may be displayed by a UA.
> 
> This makes it possible for UAs to display all elements, in spec and out,
> from version 1.0 forward without updating their code. The code would
> know about the structure, but it wouldn't have to know about the
> defined elements in the spec.

That's vague and largely unactionable. What do I do if people don't conform
to these guidelines ? Does it mean I'd effectively parse this unknown data then 
check its tree depth and other structural constraints in order to figure out whether 
it'll fit in my UI ? Then what if it doesn't ? Up to me ? What's the win of this vs. 
a well-known extension point with two levels of grouping ? If all we want is a lang
attribute and a hierarchy depth of 2, let's just define the elements and attributes 
for that and let users fill it in. So we have clear, clean, simple conformance and 
predictable results with no need to handle nearly any random input.

We're not making our lives simpler by implicitly requiring or suggesting the rendering 
of arbitrary documents. If the latter turned out to be necessary, we can still get back 
to it in a future rev of the spec, but this time on the basis of real-world use-cases and 
customer input. 

As opposed to assuming such openness is desirable by mere virtue of being possible with a few
lines of script, that the one-size-fits-all rendering of it will always be appropriate, accessible 
and usable regardless of the input, and thus needlessly over-engineering something that is supposed 
to be *metadata*.

Received on Thursday, 27 May 2010 17:55:06 UTC