RE: WOFF and extended metadata

> From: Tal Leming [mailto:tal@typesupply.com]


> Frankly, I don't really understand what you are trying to get at. Your
> arguments have been all over the place: the metadata shouldn't be XML -
> > XML is fine -> the format is impossible to parse -> the format is
> fine -> the format needs an extension block -> the extension block
> makes things too complicated. Now we're at "maybe we should ignore the
> thing that the foundries said that they wanted for awhile to see if
> they want it."

Are mischaracterizations and bad faith necessary ? The argument
is not all over the place. Although I will grant you it was unlikely to
get anywhere if all you aimed to achieve was the rubber-stamping of what 
you have previously designed. If you have no interest in feedback, it 
would have been helpful to know that earlier. As soon as the feature was 
agreed to be  optional, I could have disappeared from the thread as other 
implementors did. 

I have asked for examples of usage of this format with real fonts.
Nothing. All I get is assertions that it exists and it might therefore
not be worth anyone's time to provide me with that data. I've never 
before been on a WG where asking for real-life use-cases seems such a 
burden. It does not inspire confidence.

I also asked for use-cases of the extensibility everyone here knows
is so critical. As far as I can tell, I am the first and last
one who will ever attempt it on this thread. At least I did.

But I can't do much more without answers.

Yes, if I had to design this from scratch I would not start with XML.
And that remains my opinion (I'll add I wasn't the only browser rep who thought 
so). However, given that font designers are already using this, I can work with 
what's there. Why is that bad ? Working within the constraints you've established
is unwelcome ?

Where did I say the format was *impossible* to parse ? There is a rather
large distinction between 'more complex than needed' and 'impossible'. 

I'd rather not parse random XML, yes. I don't see why that should be needed
for file metadata. I don't think fonts are 'just images'. It doesn't follow
that I think they require the rendering of any arbitrary document embedded
in them. 

I thus proposed to structure the extension area explicitly. I came up with
a bare-bones example. Its main goal was not to define a strict XML structure 
as much as to elicit actual use-cases. I hoped font designers here would say, 
"well that doesn't work because if I wanted to do X then I would also need Y..."

Because saying "we need extensibility" is meaningless. Extensibility for *what* ?
Yet every time I ask what extensibility is *for*, the answer is: "how could be 
know ? it's for extensions!". It's like some kind of w3c Monty Python skit from hell.

I keep asking for use-cases, so we can compare proposals and pick a winner. Nothing. 
No one, as far as I can tell, even *tries* to come up with a bunch of simple scenarios 
showing how *they* would make use of this oh-so-critical extensibility with their own 
products. 

How is that reasonable ? What kind of solid design can possibly come of this 
black hole ? What can I possibly come up with that's interesting in the absence of
any useful input ?
 
In the meantime, the XML you propose turns into yet more work: with zero use-cases 
I am being told I need to resolve language attributes on property names and their 
values independently. Why is that necessary ? Well, because we don't know what people are 
going to do with it! 

The absence of any kind of use-cases or requirements is now a justification  for adding 
more features. Brilliant. 

We also learn we *need* localization in the extension area! Why ? Repeat after me: "Because 
we don't know what people might need it for". How was that going to even work earlier when 
extensions were supposed to be any arbitrary XML ? Who knows ? 

Conclusion:
1. Given that everyone agrees there needs to be extensions
2. Given that no one cares to propose meaningful real-life use-case for said extensions
3. Given that everyone else here is an expert and I am not

I have no way to propose an extension format and judge its utility, usability and relevance 
except by comparing it to other unrelated formats I am familiar with. That seems insufficient. 

Thus it is logical to fall back to where we started. In the absence of any way to design this 
feature, it may be that not designing it and watching what happens in the real world is the one
rational option I have left. If none of the experts here can propose something that makes sense 
and justify it using sound, verifiable reasoning and use-cases - as opposed to assertions, 
generalities about the self-evident goodness of extensibility and localization, even some huffing, 
puffing and other expressions of frustration at the only browser rep who even cares to understand 
how the darn thing might actually work and why - then the odds of my succeeding are rather low.
 
As the feature is optional and has thus no impact whatsoever on my browser's level of conformance, 
you may specify whatever format you wish and make it extensible, localizable, secure, scalable, 
cloud-based etc. I thought this was about designing something simple, effective and workable that 
would be easy to implement and thus get widely implemented. Clearly, the goal is to ship an appendix 
to a spec and go home. My bad for missing that important clue and wasting everyone's time. 

Moving on.

Received on Wednesday, 9 June 2010 06:46:23 UTC