RE: WOFF and extended metadata

On Wednesday, June 09, 2010 2:46 AM Sylvain Galineau wrote:
> 
> 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.
> 

With the level of scrutiny that was applied to the draft spec, the review process conducted by the WG can hardly be characterized as "rubber-stamping". Sylvain, you among many other members of the WG provided valuable comments, and this particular discussion is the direct result of it. I agree with you that mischaracterizations are unnecessary, including the allegations of "rubber-stamping".

> 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 am sorry, but this sounds like "chicken vs. egg" debate. We are developing a new format/standard that will likely bring a global change for the web typography landscape, yet you seem to be asking for a proof that this format and its usage already exist. I believe we've already discussed real-life use cases on this list, and we documented what we can foresee in the spec. Your point was that there may be something else we cannot foresee and this is why the user-defined extensions (that are easy to implement) are important. The WG agreed with you and is in the process of developing the extensions mechanism.

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

Speaking from my own experience: I know many things - one of them being that there are many more things I don't know. I would speculate that this is universally true for everybody - this is exactly the reason why I (and many members of this WG) believe the extensibility is so important. What we know today can be documented in the spec; it is what we don't know that will become use cases for metadata extensions.

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

We have already agreed that any "random" or "arbitrary" XML should be ignored, there is no reason to bring this up times and times again. We cannot forbid arbitrary XML from being present in the metadata - doing so would have required UAs to parse and validate XML which we agreed is not an option. As far as UA is concerned - "random" XML must be ignored, period. We should add this to the spec if we didn't do it already.

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

I addressed this in one of my emails [1]. IMO, the information that would be appropriate for extended metadata may include things like font character sets and script/language coverage, vendor-specific info (catalogue/database font/product ID, font category, etc). David Berlow [2] suggested that in the future the font metadata may contain a set of recommendations for font use - with their exact scope yet to be determined.

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

No one, really? Don't we all dislike "mischaracterizations"? :)
 
> 
> 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!
> 
> 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 ?
>

Fonts by their very nature are tightly coupled with languages and writing systems. The communities who speak *minority* languages are going to benefit the most from this development - this is why localization of metadata is so important. 
You proposed metadata extensions and we agreed because it makes sense. You pointed out that matching language attributes in key/value pairs can be a burden for implementers, and the WG is working to come up with mutually agreeable solution. The keyword here is "mutually" - yet you Sylvain sometimes seem to contradict everyone including yourself.

May I remind you that we are only two weeks into this development and, given the progress we made, it's pretty impressive what this WG can accomplish. Your input is valuable and very much appreciated - let's keep things positive, negativity doesn't help anyone.

Regards,
Vlad

[1] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0223.html
[2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0234.html

Received on Wednesday, 9 June 2010 20:19:02 UTC