Re: WOFF and extended metadata

Sylvain,

I'm trying to get the timeline of this part of the discussion sorted,  
I've tried to summarize.

1. The elements in the original WOFF proposal have been put together  
with lots of feedback from stakeholders. Not just foundries, but also  
UA builders.

2. Recently this group speculated on what a UA should do when  
presented with new or undefined elements. The original proposal  
suggested to just ignore them.

3. You suggested to create a new place for extension elements because  
you don't want to deal with undefined XML. Having a place for future  
data would alleviate the pressure on UA builders to update whatever  
code looks at the data. And it would enable font producers to add data  
that would be presented. WOFF already has a place for private data

4. This group looked at alternative structures of basic key / value  
pairs, following the same localization system the other undisputed  
elements have. There seem to be two competing ideas:
	a. allow localized elements for keys and values. Pro: if you're  
translating only a couple of items, you don't have to duplicate the  
whole structure. This follows the way the rest of the data can be  
localized. Con: UA needs to iterate through everything and apply some  
logic.
	b. move localization to the top level of the extension block. Pro:  
requires no logic in finding the right values for a given language, or  
matching key / value pairs. Con: localised data has to be complete,  
potentially duplicating parts of the data.

5. You find the extension elements in 4.a. too complex, and suggest 4.b.

6. You want feedback from stakeholders or usage examples on:
	a.  how they want to use the extension elements?
	b. whether they want extension elements at all?
	c.  how they want to use the elements already in the proposal?

On 7 jun 2010, at 05:13, Sylvain Galineau wrote:
> It'd be nicer if you could provide evidence of file formats where  
> either:
> 1) the metadata includes translated names for each metadata property
> 2) #1 as well as the ability to lang-match names and values separately
> are supported
> 3) their users are currently harmed by the lack of #1 and/or #2.

Are you now referring to:
	a. localization of all elements in the current proposal
	b. localization of the extension elements, either 4.a or 4.b?

Best,
Erik

Received on Tuesday, 8 June 2010 15:15:33 UTC