W3C home > Mailing lists > Public > www-font@w3.org > October to December 2010

Re: More comments on WOFF metadata

From: Tal Leming <tal@typesupply.com>
Date: Wed, 24 Nov 2010 15:43:57 -0500
Cc: <www-font@w3.org>, "public-webfonts-wg@w3.org Group" <public-webfonts-wg@w3.org>
Message-Id: <D61822BC-0C1E-400F-8D39-EDBC7E3983D6@typesupply.com>
To: Christopher Slye <cslye@adobe.com>

On Nov 19, 2010, at 12:44 PM, Christopher Slye wrote:

> Comments from my colleague Eric Muller. Apologies if some of this has been debated and resolved; better safe than sorry:
>> 1. all the WOFF elements should be in a namespace. This would address the problem raised by Laurence Penney, and is vastly preferable, IMHO, to a doctype declaration (see the philosophy of RELAX NG for the reasons)


>> 3. Once you have a namespace machinery, extensibility is typically provided by allowing elements of a different namespace. This also solves neatly the problem of multiple sources contributing to the extension, without having to install a registry.
>> 4. I suspect that the type xsd:NCName is too constraining for lang attributes, which ought to allow BCP47 names.

Would adding these requirements make existing files invalid?

>> 2. since the intention of the metadata is primarily to be presented to humans, localizability and accessibility seem important.
>> 2.1 On the localizability side, I would have expected that an element like <description> would allow multiple <text> elements, each with different lang attributes.

This is already in the spec.

>> 2.3 on the accessibility side, because metadata often contain names (e.g. credits/credit/@name), a plain text value is generally not enough. The common practice is to allow structured text, and in particular to support pronunciation and sorting metadata (which would be meta-metadata in this case).

Structured text has been discussed several times and it was decided that it is a can of worms that we want to avoid. This should be in the list archive.

>> 5. Licenses are not just translations of a text in different languages, they are also adaptations to local laws. I think this implies that the url and id attributes should instead be on the various <text> elements inside <license>.

Hm. The URL that the license element is directing the user to could handle this, no?

This last point brings up a change that we may need to make to the spec. We say that "at least one text subelement MUST be present" in elements that can be localized. In the case of the license we may want to make an exception. There could be no text elements there since the URL attribute could be doing all of the work.

Received on Wednesday, 24 November 2010 20:44:30 UTC

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