Re: .webfont Proposal 2

Thomas Lord wrote:

> If the intention of the format is to be easily 
> extended with new font file formats, there must be
> some assignment of authority over that list to some
> organization and an orderly process for managing the 
> list -- so that people can register new format names,
> avoid name collisions, ensure that an adequate definition
> for each new format name is recorded, and so forth.
> 
> To what organization do you suggest that authority 
> should be assigned and what process should be used 
> to maintain it?

There are at least four reasonable answers to that question:

1) In the case of the '@font-face' rule of CSS, the CSS2 spec itself
defines a list of names. A Web font specification could do the same. Or
it could reference the CSS spec. The latter makes sense, because the
font format and the '@font-face' rule are meant to complement each other
and probably need to refer to exactly the same font formats.

Such a list can be extended, when the need arises, by revising the CSS
specification.

The latest working draft of the CSS Fonts module extends the list from
1998 with SVG fonts, but it also contains an open issue that asks if a
separate mechanism is needed. (CSS in general allows experimental and
proprietary names to be coined with a special prefix, which is normally
enough, but it is good to ask the question if it is enough for font
formats, too.)

2) You can defer to IANA, via its registry of Media Types (a.k.a., MIME
types). The name would in that case be of the form
"application/opentype" (i.e., not a single identifier, but two parts
with a slash in between).

There are currently no font formats in IANA's registry, as far as I
know, but it makes sense to register some. Some operating systems
already use pseudo-media types internally: e.g., KDE uses
application/x-font-otf.

W3C has a special liaison with the IETF and the procedure for
registering new types in the context of a W3C Recommendation is
relatively simple.

3) Very rarely, W3C decides to create a registry separate from the
format specification. I know of only one: the registry for XPointer
types[1].

[1] http://www.w3.org/2005/04/xpointer-schemes/

4) You can use a "self-organizing" registry, which means: use a URL to
identify the format. That is how RDF vocabularies ("ontologies") get
their identifier. The assumption is that everybody who needs a new
identifier is likely to have (or is able to get) control over some
domain or some part of a URL space and can thus make URLs. And if not,
W3C can mint a URL, if asked.

The advantage is that it is cheap and easy to make new identifiers, the
disadvantage is that there is absolutely no review: is the new
identifier needed? is it a duplicate? will anybody actually use it?
(This is not a big issue for RDF, because RDF is meant to be rich enough
to express how vocabularies relate to each other, using the rules of OWL.)


But let's not run ahead of ourselves. Maybe it turns out to be easy to
define and implement font-format agnostic Web fonts, but I wouldn't make
it a requirement to support multiple formats. OpenType still has a
couple of years of life in it, I think, and if we can get everybody to
agree to support embedded fonts based on OpenType and only OpenType, I'd
already be quite happy.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 16 July 2009 18:43:26 UTC