Re: WOFF and extended metadata

Vlad,

Might I suggest that you and the other proposers point to existing successful metadata schemes that are similar to each of the three techniques you describe? My scheme, which you omit, is used (unnested) all over OpenStreetMap, and an apparently similar but nested scheme, Matro$(D+^(Bka [1], thanks to its adoption by Google in the forthcoming VP8 codec, looks like it's on the verge of heavy usage in the field of video tagging, including multi-lingual subtitles and credits of the type Tal has already defined in WOFF.

Nesting capability seems to be lacking in the three schemes below. Do you seriously believe this is not a significant requirement for metadata?

Your list also seems to be lacking a means by which any metadata schemes initiated by one party might be adopted as a standard. (Let's imagine a scenario where the current WOFF metadata had not yet been placed in any fonts - how would a 'credit' metadata scheme be adopted as normative by W3C?)

I propose that our metadata scheme must be capable of elegantly representing anything representable as JSON - that is: numbers, strings, arrays and dictionaries (aka key-value pairs), to arbitrary levels of nesting. In addition, because these structures will, in general, be sparse in terms of human language coverage, the language tagging should be as close to the data as possible. Whether that is with a lang attribute or a colon syntax is of minor concern.

Proposed use cases: tagging the Font Aid "Coming Together" font[2]

1. Give each glyph a designer credit
2. Record the name of the receiving charity and the reason for the appeal

- L

[1] http://en.wikipedia.org/wiki/Matroska http://www.matroska.org/
http://www.matroska.org/technical/specs/tagging/index.html
[2] http://new.myfonts.com/fonts/fontaid/coming-together/

On 16 Jun 2010, at 16:46, Levantovsky, Vladimir wrote:

> In order to facilitate the discussion and reach a consensus on this issue, I'd like to offer my personal opinion on different options under consideration:
> 
> 1) Localizable metadata extension as proposed by Jonathan Kew [13] (with detailed description of the simple set of rules) - this is my personal favorite:
> 
> <extension lang="en"><!-- untagged subelements are English -->
>  <item>
>    <name>Message</name>
>    <name lang="nl">Bericht</name>
>    <name lang="fr">Message</name>
>    <value>Hello!</value>
>    <value lang="nl">Hallo!</value>
>    <value lang="fr">Salut!</value>
>    <value lang="fr-CA">Bonjour!</value>
>    <value lang="ja">$B$3$s$K$A$O!#(B</value>
>  </item>
> </extension>
> 
> 2) Localizable metadata extension where only the <extension> element is tagged with lang attribute (a variation of what Sylvain has proposed [12]). Multiple extension elements would be needed to localize the content but since the repetitive elements are compressed well, this shouldn.FN"t be a problem as far as the size of metadata is concerned:
> 
> <extension lang="en">
>  <item>
>    <name>Message</name>
>    <value>Hello!</value>
>  </item>
> </extension> 
> <extension lang="fr">
>  <item>
>    <name>Message</name>
>    <value>Salut!</value>
>  </item>
> </extension> 
> <extension lang="nl">
>  <item>
>    <name>Bericht</name>
>    <value>Hallo!</value>
>  </item>
> </extension>
> 
> 3) Metadata extension with no localization, only consisting of the sets of key/value pairs (with potential group attribute as originally proposed by Sylvain [4]). If needed, the key/value pairs can simply be presented and displayed in multiple different languages (may not be the best choice because the user would see duplicate entries, but simple to implement and I can live with it):
> 
> <extension>
>  <item>
>    <name>Message</name>
>    <value>Hello!</value>
>  </item>
>  <item>
>    <name>Bericht</name>
>    <value>Hallo!</value>
>  </item>
>  <item>
>    <name>Message</name>
>    <value>Bonjour!</value>
>  </item>
> </extension>
> 
> 
> Speaking with my WG chair hat 'on' - I believe we all agreed that there are many benefits in offering an extension mechanism for metadata. We have rather strong opinions expressed by the people from the industry [1] and I would like us to make every possible effort to come up with a solution that both font vendors and UA implementers can be comfortable with. Please respond to this message indicating you preferred choice(s) of metadata extension mechanism.
> 
> Thank you and best regards,
> Vlad
> 
> 
>> -----Original Message-----
>> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
>> request@w3.org] On Behalf Of Levantovsky, Vladimir
>> Sent: Friday, June 11, 2010 3:55 PM
>> To: Sylvain Galineau; Tal Leming
>> Cc: Erik van Blokland; www-font@w3.org; 3668 FONT
>> Subject: RE: WOFF and extended metadata
>> 
>> Hello all,
>> 
>> Thank you for your active participation and your contributions to the
>> work of this WG.
>> 
>> In an effort to move things forward I'd like to try to "refresh" this
>> discussion and document its timeline, the issues we discussed to date,
>> and the outcome of those discussions. I hope that by doing this we will
>> be able to see the progress we made and focus our energy on the
>> remaining issues.
>> 
>> 1. Metadata use cases
>> The use of metadata and the importance of its content has been
>> addressed in a number of contributions that, in particular, represent
>> the industry perspective and the possible need for localization and
>> extensibility [1-3]. Some use cases for metadata extensions have been
>> offered [4, 5]; however it would be desirable to include specific
>> examples of metadata content that can be included in the WOFF
>> specification. I would like to ask people to contribute these examples
>> (both for metadata elements that already defined and possible scenarios
>> for future extensions).
>> 
>> 2. Metadata format
>> I believe we have reached the consensus that
>> - metadata elements defined in the spec may be rendered by UA if
>> requested by the user;
>> - if arbitrary (not defined by the WOFF spec) XML elements are added to
>> metadata, they will be ignored;
>> - the currently defined set of metadata elements is acceptable both for
>> font vendors and implementations.
>> In particular, Sylvain has stated that he is okay with parsing and
>> rendering the currently defined schema [6], and proposed to consider
>> specifying the extension mechanism that would allow font vendors to
>> define additional metadata and show it to the user (which he proposed
>> earlier in [4]).
>> 
>> 3. Metadata extensibility
>> The mechanism proposed for metadata extensions was originally based on
>> a simple key/value pairs with the possibility to group them into higher
>> level categories [4]. A derivative format was proposed to enable
>> localization of the proposed metadata extensions [7]. However, the
>> discussion of this proposal [8-11] revealed potential implementation
>> issues where a rather complex set of rules would have to be developed
>> to insure proper rendering of multiple localized name/value pairs.
>> Alternatively, other proposals were presented to simplify rendering by
>> introducing "lang" attribute at the higher element level [12,13]. So at
>> that point (as summarized by Erik in [14], p.4a&b) we have two
>> alternative structures. Another alternative was recently proposed by
>> Laurence Penney [15].
>> 
>> In conclusion, given that we already have a consensus on some core
>> issues (as mentioned in p.2 of this email) I would like to ask the WG
>> members to review the alternative approaches to enable metadata
>> extensibility giving proper considerations to the following questions:
>> - localization and extensibility are both important, but considering
>> the extremes of this issue - would we rather have localizable metadata
>> without extensibility or extensible metadata with no localization?
>> - among the alternative options we currently have under consideration -
>> which one is the most likely to satisfy the needs of font vendors and
>> address concerns of the implementers?
>> - how can we simplify the structure of the metadata extensions to make
>> it easier for browsers to render and display its content? (therefore
>> making it much more likely for users to be able to see metadata, which
>> is the goal)
>> 
>> I also would like to ask group members to contribute your ideas and use
>> cases for metadata extensions, and examples of metadata content that
>> can be incorporated in the WOFF spec.
>> 
>> Thank you,
>> Vlad
>> 
>> P.S. Every possible effort was made to accurately represent the essence
>> of our discussions and to reference the source where appropriate. Many
>> contributions on this subject offered useful ideas and insight, however
>> it was impossible to include all of them in the list of references
>> below. Please consider using WG public archive
>> (http://lists.w3.org/Archives/Public/public-webfonts-wg/) as a primary
>> reference.
>> 
>> [1] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0235.html
>> [2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0234.html
>> [3] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0050.html
>> [4] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0201.html
>> [5] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0223.html
>> [6] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0209.html
>> [7] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0004.html
>> [8] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0010.html
>> [9] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0013.html
>> [10] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0017.html
>> [11] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0016.html
>> [12] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0021.html
>> [13] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0023.html
>> [14] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0047.html
>> [15] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0304.html
>> 
> 
>

Received on Wednesday, 16 June 2010 17:26:55 UTC