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

RE: WOFF and extended metadata

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 27 May 2010 22:05:20 +0000
To: Tal Leming <tal@typesupply.com>
CC: 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>
Message-ID: <045A765940533D4CA4933A4A7E32597E214950E7@TK5EX14MBXC120.redmond.corp.microsoft.com>
From: Tal Leming [mailto:tal@typesupply.com] 

> Honestly, I'm having a hard time following you as well.

Fair enough :)


> Okay, so your code would support this abstraction:

Not quite. I don't allow arbitrary XML. I define the element and attribute names to use.
More below.

>> What do I do if people don't conform
>> to these guidelines ? Does it mean I'd effectively 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 ? Then what if it doesn't ? Up to me ?

>All of this applies to your proposal as well. We have to answer these questions no matter what direction we go in.

Not quite. In my proposal, what must be rendered is explicitly and completely defined. 

Because I do not see the logic or benefit of requiring both adherence to a clearly defined format *and* also
require the UA to render any arbitrary content; first because it is metadata and should be very simple; second 
because we either specify it or we don't. Telling people to follow a strict format *and also* "please add any XML 
you want, we will render it too !" is self-contradictory and self-defeating from a conformance standpoint. Why 
would I bother following the XML format you and Erik have defined if what I store in this block will be rendered by the 
browser anyway ? 

So I am adding an optional extension point to your schema. I called it <metadata-extended>. In this extension point, 
one can add as many property elements as they'd like. You can tag them with a lang attribute. You can tag them 
with a group attribute to put them in buckets. The value of each property is also set using an attribute. If one level 
of grouping is not enough, we can add an optional <properties name="xxx"> element to add a level of structure. 

(See previous example again below; make sure to go to the bottom)

And that is the entire schema we specify. If a font vendor adds data according to this exact convention, the browser
renders it. The extensibility constraints are 100% explicit and defined by the XML itself, not by vague general prose 
guidelines in a spec such as "your XML should be at most so many level deep, there is this lang attribute you may use
for this purpose" etc etc. This is a clear contract just like the one you have already defined with your own schema. 

And if we don't need to define a schema for these extensions, then why do we need to define a schema for any
of the metadata at all ? If an XSLT transform or a script is enough to render arbitrary XML then let's just say the 
metadata block is any XML and render the whole thing. Let browsers worry as to whether and how they'll render it. 
This will save the WG time and enable font vendors to encode their metadata however they want.

Clearly, we've taken the position that we'd rather standardize this metadata. I don't see why we can't also standardize
a simple, clear mechanism to add to it as well. It's only metadata.

<?xml version="1.0" encoding="UTF-8"?>
<metadata version="1.0">
    <uniqueid id="com.example.fontvendor.demofont.rev12345" />
    <vendor name="Font Vendor" url="http://fontvendor.example.com" />
    <credits>
        <credit
            name="Font Designer"
            url="http://fontdesigner.example.com"
            role="Lead" />
        <credit
            name="Another Font Designer"
            url="http://anotherdesigner.example.org"
            role="Contributor" />
        <credit
            name="Yet Another"
            role="Hinting" />
    </credits>
    <description>
        <text lang="en">
            A member of the Demo font family.
            This font is a humanist sans serif style designed
            for optimal legibility in low-resolution environments.
            It can be obtained from fontvendor.example.com.
        </text>
    </description>
    <license url="http://fontvendor.example.com/license"
             id="fontvendor-web-corporate-v2">
        <text lang="en">A license goes here.</text>
        <text lang="fr">Un permis va ici.</text>
    </license>
    <copyright>
        <text lang="en">Copyright ©2009 Font Vendor"</text>
        <text lang="ko">저작권 ©2009 Font Vendor"</text>
    </copyright>
    <trademark>
        <text lang="en">Demo Font is a trademark of Font Vendor</text>
        <text lang="fr">Demo Font est une marque déposée de Font Vendor</text>
        <text lang="de">Demo Font ist ein eingetragenes Warenzeichen der Font Vendor</text>
        <text lang="ja">Demo FontはFont Vendorの商標である</text>
    </trademark>
    <licensee name="Wonderful Websites, Inc." />

    <!-- ...and now the metadata that wasn't in the spec but makes the life of this font vendor
         easier if it's here, regulatory tidbits useful in some countries, useful metadata for a 
         certain design tool lots of people use etc -->

    <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" />
	<properties name="legal">
		<property group="EU" name="CopyrightNumber" value="FR-33323-2010" />
		<property group="EU" name="CopyrightGrantDate" value="20111021" />
	</properties>
	<property group="AdobeDreamweaver" name="category" value="headline" />
	<property group="AdobeDreamweaver" name="recommended-min-size" value="14pt" />
    </metadata-extended>
</metadata>




Received on Thursday, 27 May 2010 22:06:01 UTC

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