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

RE: WOFF and extended metadata

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Fri, 18 Jun 2010 12:15:18 -0400
To: Sylvain Galineau <sylvaing@microsoft.com>, Laurence Penney <lorp@lorp.org>
CC: Tal Leming <tal@typesupply.com>, Erik van Blokland <erik@letterror.com>, "www-font@w3.org" <www-font@w3.org>, 3668 FONT <public-webfonts-wg@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D03F3BF24E2@wob-email-01.agfamonotype.org>
On Wednesday, June 16, 2010 7:18 PM Sylvain Galineau wrote:
> And if we're defining the
> schema then we can certainly allow nesting if it is useful. It can be
> arbitrarily deep; but if one accepts that the requirement to render
> arbitrarily deep data trees is not equivalent to rendering data of a
> known depth to those doing that rendering ... 
> <snip/>
> ... I personally think it's OK for UAs to assume a relatively
> limited depth in designing their UI if they so choose i.e. it should be
> up to the browser as to whether they want to support 'infinite' depth
> or, say, up to 8.

I agree.

> Fwiw, Laurence's non-XML key-value pair scheme is something I would
> originally have expected to be sufficient. An XML equivalent, wrapped
> by language-tagged container, seems reasonable. I am comfortable having
> each property element specify both a name and a value through
> attributes, with nested properties if need be. 

It sounds like we have the grounds for consensus here - in this particular case I personally do not have a strong preference in "attributes vs. elements" debate, and attributes can easily be used to define the key/value pairs.

> It has been pointed out
> that in some cases the value might need its own markup e.g. Ruby
> annotation for Japanese Kanji in which case attributes are undesirable.
> <snip/>
> I understand why HTML and CSS need to address Ruby and I like
> that they attempt to. But they're not simple metadata formats meant to
> describe a specific resource type.


> This, however, is not a web page, it's font metadata. If something
> cannot be described in it that would be better done using a capable
> document format with styling capabilities such as HTML+CSS then use the
> metadata to include a descriptive link to a page with the information.
> We are talking about browsers here, after all. Following links is not
> unnatural :)

So, to recap what's just been said - we seem to agree that the following metadata structure with extension mechanism and agreed upon, finite nesting depth (e.g. up to 8) would be an acceptable solution (where [...] indicates an implied attribute):

  <!-- elements already defined by the WOFF spec go here -->
  <extension [lang="tag"]>
    <item [lang="tag"] name="group_name" value="group_value">
      <item [lang="tag"] name="property_name1" value="property_value1"/>
      <item [lang="tag"] name="property_name2" value="property_value2"/>
      <!-- where any of the items, if needed, could be -->
      <item name="URL" value="http://link.to.external.doc"/>
      <!-- that provides additional info for a user -->
  <extension [lang="tag"]>

If this is the case, I would like to ask all WG members to state their position on this proposed structure to see if we have a consensus.

Thank you and regards,
Received on Friday, 18 June 2010 16:17:09 UTC

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