RE: WOFF and extended metadata

>You are going way beyond the narrow context in which my question was posed.
>During the meeting, the question was asked: If a WOFF file has invalid XML metadata, should the entire file be rejected, or should only the metadata be rejected? I was only positing a case for the former.

You're not answering my question: what *for* ? You seem to take it as self-evident that rejecting font files on this basis is a good thing, or that it would make the web a demonstrably better place for font vendors. 

I don't see why; and I've gone much further in order to argue in the most concrete manner possible that thw case has in fact not been made. 
I don't understand how leaving authors and users hanging because someone screwed up a bit of XML neither have anything to do with makes web fonts better. If I am going to burn extra CPU cycles parsing data no one will read in the vast majority of cases, that's a concern. 

A trade-off is being requested from browser vendors, authors and users. I think it's fair to expect font vendors to justify this trade-off and clearly explain what concrete expectations they have from this requirement and why and how this proposal fulfills them. 



________________________________________
From: www-font-request@w3.org [www-font-request@w3.org] on behalf of Christopher Slye [cslye@adobe.com]
Sent: Wednesday, May 19, 2010 10:57 PM
To: public-webfonts-wg@w3.org
Cc: www-font@w3.org
Subject: Re: WOFF and extended metadata

You are going way beyond the narrow context in which my question was posed.

During the meeting, the question was asked: If a WOFF file has invalid XML metadata, should the entire file be rejected, or should only the metadata be rejected? I was only positing a case for the former.

That's it. I wasn't proposing a "schema". My assumption, based on the question having been asked, was that XML validation (i.e. confirming the code in the block is valid XML) was already taking place. I think what you're saying is that that's not the case.

It would in fact be better for foundries if there was a more comprehensive schema that was required to ensure metadata was untainted (something that usually requires a dsig), but that wasn't what I was suggesting and I understand it's not practical.

-C


On May 19, 2010, at 7:11 PM, Sylvain Galineau wrote:

>> Some foundries might choose to include what they consider very important information there.
>> For example, they might include customer information that will help them recognize legal web fonts.
>
>> The overarching questions is this: If a foundry chooses to include extended metadata in a WOFF file, shouldn't that be considered an inextricable component of the WOFF? Yes, the creator of the WOFF is not required
>> to put it there, and the UA is not required to do anything with it, but still, should the UA be permitted to accept the font data without its accompanying metadata?
>
> The question is what do you expect the UA to validate ? And what does it mean ?
>
> Just checking for XML well-formedness would not buy you anything. Yay, it parses as XML ! I can just put <foo>bar</foo> in there and it'll work.
>
> If you want to make sure it's valid according to some schema, that may be technically possible but a huge pain in practice. Those things evolve and get versioned, font vendors in different countries may want different schemas....Long story short: this is a huge rathole no UA vendor will want to touch (assuming the tool vendors want to). But even assuming for a moment that we can easily do this - maybe the metadata format never revs because it's blind collection of name-value pair, for instance - then what does it mean that the metadata is a valid document ? How can the browser possibly verify that the actual *data* in the metadata block has any kind of validity or relevance with respect to the font data it came with ? How does the UA determine the metadata block's content is *invalid enough* for the whole font to be ignored ?
>
> So what the UA *can* validate easily and efficiently cannot possibly be that useful to you because it's structural in nature. The UA can't tell what data is important or assert its correctness. All it can really say is that there is a license, that a machine can parse it and that it obeys very simple constraints e.g. "there is a vendor name".
>
> Same exact thing for the tool vendor. They'll prompt the user with a form, create the right XML but have no way to verify whether the input makes sense in any kind of useful way.
>
> Thus the question for you is: what do you expect the concrete benefits of adding such UA validation constraints to be for you as a font vendor ? And why do they justify giving the user the wrong font ?
>
> The only benefit I can think of right now is that tool vendors are less likely to produce bad XML if browsers reject the font. And if I have UI to display this info to the user, I'm more likely than not to have something clean to render.
>
> But:
> - I'd have to pay the price of decompressing and parsing this every single time. It isn't 'pay to play' i.e. all users would pay for this in CPU cycles whether or not they care to access this info.
> - The browser that skips this validation will appear to 'work' from the perspective of an author using a bad tool. The author's reaction is not going to be that clearly, the browser that does what he wants is non-conformant! Not the best incentive for browser makers to comply.
> - Font vendors, authors and end-users would suffer the occasional mistakes and bugs of tool makers for some time to come e.g. the tool works great as long as the user does not insert a certain character in the license form UI that should be escaped in XML
> - And of course all UAs would have to do this to reap the full benefits, whatever they may be. Yet I very much doubt phone browsers will bother providing a UI to display this info and spend their precious CPU cycles and battery power parsing it.
>
>

Received on Thursday, 20 May 2010 21:21:18 UTC