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

Re: WOFF and extended metadata

From: Chris Lilley <chris@w3.org>
Date: Thu, 20 May 2010 12:57:13 +0200
Message-ID: <1883954218.20100520125713@w3.org>
To: Tal Leming <tal@typesupply.com>
CC: John Daggett <jdaggett@mozilla.com>, Christopher Slye <cslye@adobe.com>, <www-font@w3.org>, <public-webfonts-wg@w3.org>
On Thursday, May 20, 2010, 12:42:14 PM, Tal wrote:

TL> On May 20, 2010, at 4:19 AM, John Daggett wrote:

>> In many cases a better process would
>> involve a separate tool that handled the XML validation, in which case
>> requiring XML validation as part of the WOFF tool would be unnecessary.

TL> For what it is worth, my WOFF validator does this [1]. It checks
TL> to see if the XML can be parsed and issues an error if it can't.

Good. At minimum, it must be well formed.

TL> If the XML can be parsed, it checks to see how closely the data
TL> follows the specification. Among other things, this checks for an
TL> improperly structured top-level element, for unknown elements, for
TL> missing elements, for duplicated elements and for unknown
TL> attributes in elements. For each of these tests, various levels of
TL> reports are issued: note, warning, error, pass [2].

So, that is a type of validation. Its a useful type, along thge lines of sanity checking, rather than the (mostly) useless non-extensible type that DTD validation gives you.

TL> All of this brings me to the question of what "valid" means.

Yes. I think the term has been used somewhat loosely in the conversation so far.

TL>  As
TL> we have it defined in the current spec [3], we say that the
TL> metadata must be well-formed XML.

That is a crisper way of putting it.

TL>  There are one required element
TL> ("metadata"), two recommended elements (uniqueid, vendor) and a
TL> bunch of optional elements. 

And the spec does not say what happens if a required element is omitted, present twice, present in the wrong place, etc.


That is well formed, but the elements are in the wrong place.

TL> We don't say anything about unknown
TL> elements being allowed or disallowed. Nor do we say anything about
TL> element attributes that do not follow the spec. 

I agree that should be clarified.

TL> As best as I can
TL> remember, during our discussions while we were writing the spec we
TL> said that unknown elements or elements that don't follow the
TL> defined structure should be ignored by UAs that wish to display
TL> this data. Perhaps we should make this more clear in the spec.

That sounds like a reasonable balance between extensibility and validation. I would add the same for unknown attributes.

TL> [1]
TL> http://code.typesupply.com/browser/packages/woffTools/trunk/Lib/woffTools/tools/validate.py#L468
TL> to
TL> http://code.typesupply.com/browser/packages/woffTools/trunk/Lib/woffTools/tools/validate.py#L1014
TL> [2] I may have it set to be more strict than the spec requires.
TL> This is on my list of things to re-examine once we have more concrete agreement on the spec.
TL> [3] http://www.w3.org/Submission/2010/SUBM-WOFF-20100408/#appendix-a

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Thursday, 20 May 2010 10:57:24 UTC

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