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

Re: WOFF and extended metadata

From: Dave Crossland <dave@lab6.com>
Date: Fri, 28 May 2010 00:37:28 +0200
Message-ID: <AANLkTimGte4pSWkQdykJw3mIKI_vU5ukjxWr09auOBhj@mail.gmail.com>
To: Tal Leming <tal@typesupply.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Jonathan Kew <jfkthame@googlemail.com>, Vladimir Levantovsky <Vladimir.Levantovsky@monotypeimaging.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
On 27 May 2010 17:18, Tal Leming <tal@typesupply.com> wrote:
> On May 26, 2010, at 6:18 PM, Sylvain Galineau wrote:
>>    <metadata-extended>
>>       <property group="catalog-info" name="RefID" value="AAA-6667" />
>>       <property group="catalog-info" name="UnicodeRange" value="standard" />
>>       <property group="catalog-info" name="UpdateURI" value="http://www.fontvendor.com/update/AAA-6667" />
>>       <property group="EU" name="CopyrightNumber" value="FR-33323-2010" />
>>       <property group="EU" name="CopyrightGrantDate" value="20111021" />
>>       <property group="AdobeDreamweaver" name="category" value="headline" />
>>       <property group="AdobeDreamweaver" name="recommended-min-size" value="14pt" />
>>    </metadata-extended>
> What if we do something more simple? We could add a section to the Extended Metadata section about extensions. It could say something like:
> Extensions to the metadata are allowed, but they may not be displayed by UAs. If extensions are added, they must not be nested any deeper than two levels from the top-level metadata element.

I like the first sentence very much. I'm not sure about the second -
adding conditions ("must not be nested more than 2 levels") seems to
actually makes it less simple (Sylvain, "parse this unknown data then
check its tree depth")

I don't see the first sentence as an alternative but rather
complementary to Sylvain's

       <property group="credits" name="credit" value="Font Designer" />
       <property group="credits" name="role" value="Lead" />
       <property group="credits" name="crediturl"
value="http://fontdesigner.example.com" />
       <property group="credits" name="credit" value="Another Font Designer" />
       <property group="credits" name="role" value="Contributor" />
       <property group="credits" name="crediturl"
value="http://anotherdesigner.example.org" />
       <property group="credits" name="credit" value="Yet Another" />
       <property group="credits" name="role" value="Hinting" />

parse this unknown data then
check its tree depth and other structural constraints in order to
figure out whether
it'll fit in my UI ?

> This would limit the depth of the nesting to what we have in the spec now. You made a
> good point about not wanting UAs to have to update each time a new element is added
> to the spec. I think that by not defining a specific extension syntax like the above, we
> could achieve that goal. Everything would be allowed, as long as it followed the nesting
> limits. A UA could implement a "show everything" UI now and not have to worry about
> updating when metadata version 3.7 comes along.

UAs won't have to update,

On 27 May 2010 17:21, Sylvain Galineau <sylvaing@microsoft.com> wrote:
> To be clearer on what I proposed from a spec standpoint:
> 1. When a user agent renders the metadata block for the user, it SHOULD attempt to render
> all the data elements specified in the format we define.
> 2. If a user agent finds XML that is not defined in the spec, it MAY ignore it.
> These two requirements remain the same whether we agree on specifying an extension area,
> or whether we prefer allowing arbitrary XML extension in the metadata block.
Received on Thursday, 27 May 2010 22:38:27 UTC

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