W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: WOFF and extended metadata

From: Tal Leming <tal@typesupply.com>
Date: Fri, 28 May 2010 11:46:12 -0400
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Jonathan Kew <jfkthame@googlemail.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-Id: <E009F0D6-C479-4709-A341-2FDF6F743EC2@typesupply.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>

On May 28, 2010, at 9:46 AM, Levantovsky, Vladimir wrote:

> I don't think the intention is to lock down the metadata spec and *never* add new elements - I'd say that specifying the metadata extension mechanism will significantly reduce the need to rev the spec just to add new metadata, but we still can do it if and when the needs arise.

Of course. What I mean is that for font makers there is no point to adding official elements to the spec after 1.0 if major implementations won't ever show the new fields. Yes, all font makers could agree to could put the new industry standard blahblah element inside of the extension/vendor/whatever block, but that isn't an ideal solution. I understand Sylvain's logic behind all of this and I don't disagree with it. It is a new wrinkle that was not clear, at least to me, until last night.

Now that I understand the core of the problem that Sylvain is trying to address, I'm leaning towards some sort of extension block. What I do know for sure is that we need to be absolutely certain that we have all the official elements we need in the metadata 1.0 spec. Erik and I put that together last year. It's a collection of fields from formats that we have worked with and studied. We added new things that we thought would help with some common problems. If other font people want to add to the official elements, take things away or modify, now is the time.

> Another benefit of this extension mechanism is that it allows vendors to easily specify metadata that is arbitrary and guaranteed to be visible at the same time. For example, we would not want to rev the spec to accommodate vendor-specific metadata, yet this could be something some vendors would very much like to happen. With the extensions mechanism defined - there is no need to rev the spec. I can include vendors specific metadata (such as my product IDs, transaction ID if fonts are licensed online, etc.) that is not defined by the spec - this vendor-specific info could help our tech support to handle possible calls from the field yet standardizing it as part of the spec may not make much sense for other vendors.

Yes, that is obvious.

Received on Friday, 28 May 2010 15:46:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC