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

Re: WOFF and extended metadata

From: Tal Leming <tal@typesupply.com>
Date: Wed, 2 Jun 2010 06:58:59 -0400
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: <F3120150-DF2F-457E-B04E-26C501350AF9@typesupply.com>
To: Sylvain Galineau <sylvaing@microsoft.com>

On May 27, 2010, at 6:05 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" />
> 	<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>

I've given this a proposal a lot of thought and played out it out across different scenarios. On the one hand, it allows for extensions. That is good in light of the > 1.0 issues that were discussed. On the other hand, it doesn't allow for localization. The existing metadata elements do allow for localization where appropriate, so I think that the extension block should as well. It also doesn't follow the same pattern as the existing metadata, which seems odd to me. I think these problems can be solved. Below is a rough draft of an idea that I think retains the strengths of the proposal and addresses the problems.

	<extensions>
		<group id="string">
			<!--
				group is a container. It must contain at least one item element.
				It may contain more than one element. If so, the items should be
				displayed together in the UI.

				The optional id attribute allows for tagging the group with an arbitrary
				identification value. This should not be shown to users.
			-->
			<name>
				<!--
					This optional element should contain one or more group names, each stored
					in a text element. These text elements may be given a lang attribute. The
					possible values for the lang attribute can be found in the IANA Subtag
					Registry. UAs are expected to apply the same rules for selecting the
					appropriate name to display as they do for selecting appropriate text
					elements as described above.
				-->
				<text lang="tag">string</text>
			</name>
			<item id="string">
				<!--
					This is a coordinated set of name and value strings to be displayed by UAs.

					The optional id attribute allows for tagging the item with an arbitrary
					identification value. This should not be shown to users.
				-->
				<name>
					<!--
						This element contains the one or more localized names, each stored in a
						text element. These text elements may be given a lang attribute. The
						possible values for the lang attribute can be found in the IANA Subtag
						Registry. UAs are expected to apply the same rules for selecting the
						appropriate name to display as they do for selecting appropriate text
						elements as described above.
					-->
					<text lang="tag">string</text>
				</name>
				<value>
					<!--
						This element contains the one or more localized values, each stored in a
						text element. These text elements may be given a lang attribute. The
						possible values for the lang attribute can be found in the IANA Subtag
						Registry. UAs are expected to apply the same rules for selecting the
						appropriate value to display as they do for selecting appropriate text
						elements as described above.
					-->
					<text lang="tag">string</text>
				</value>
			</item>
		</group>
	</extensions>

An example:

	<extensions>
		<group>
			<!--
			The author wants the UI to show:

			Catalog Info:
			Ref ID: AAA-6667
			Unicode Range: standard
			Update URI: http://www.fontvendor.com/update/AAA-6667

			(Credit: This was one of Sylvain's examples.)
			-->
			<name>Catalog Info</name>
			<item>
				<name>
					<text>Ref ID</text>
				</name>
				<value>
					<text>AAA-6667</text>
				</value>
			</item>
			<item>
				<name>
					<text>Unicode Range</text>
				</name>
				<value>
					<text>standard</text>
				</value>
			</item>
			<item>
				<name>
					<text>Update URI</text>
				</name>
				<value>
					<text>http://www.fontvendor.com/update/AAA-6667</text>
				</value>
			</item>
		</group>
		<group>
			<!--
			The author wants the UI to show:

			EU Greeting:
			Message: Hello!
			Date: 2010-06-01

			With an appropriate language chosen from the
			English, Dutch and French localizations.
			-->
			<name lang="en">EU Greeting</name>
			<name lang="nl">EU Groet</name>
			<name lang="fr">EU Salut</name>
			<item>
				<name>
					<text lang="en">Message</text>
					<text lang="nl">Bericht</text>
					<text lang="fr">Message</text>
				</name>
				<value>
					<text lang="en">Hello!</text>
					<text lang="nl">Hallo!</text>
					<text lang="fr">Bonjour!</text>
				</value>
			</item>
			<item>
				<name>
					<text lang="en">Date</text>
					<text lang="nl">Datum</text>
					<text lang="fr">Date</text>
				</name>
				<value>
					<text lang="en">2010-06-01</text>
					<text lang="nl">2010-06-01</text>
					<text lang="fr">2010-06-01</text>
				</value>
			</item>
		</group>
	</extensions>

Granted, this is verbose. It could be simplified into something more like this:

	<extensions>
		<group>
			<name lang="tag">string</name>
			<item>
				<name lang="tag">string</name>
				<value lang="tag">string</value>
			</item>
		</group>
	</extensions>

However, that would break the similarities with the top-level structures. This could make things confusing. For example, in working thorough this, Jonathan, Erik and I noted that the WOFF metadata spec should probably say more about localization fallbacks in the top-level structure. If the extension structure is the same, we can have one global set of localization notes. If the extension structure is different, we have to break things apart. Clarity seems better than saving some lines of XML.

Liam also brought up the idea of two separate blocks: one that UAs would show and one that UAs would not show. I'm curious to know what others think of this.

Tal
Received on Wednesday, 2 June 2010 10:59:44 UTC

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