- From: Tal Leming <tal@typesupply.com>
- Date: Thu, 20 May 2010 06:42:14 -0400
- To: John Daggett <jdaggett@mozilla.com>
- Cc: Christopher Slye <cslye@adobe.com>, www-font@w3.org, public-webfonts-wg@w3.org
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. For what it is worth, my WOFF validator does this [1]. It checks to see if the XML can be parsed and issues an error if it can't. If the XML can be parsed, it checks to see how closely the data follows the specification. Among other things, this checks for an improperly structured top-level element, for unknown elements, for missing elements, for duplicated elements and for unknown attributes in elements. For each of these tests, various levels of reports are issued: note, warning, error, pass [2]. All of this brings me to the question of what "valid" means. As we have it defined in the current spec [3], we say that the metadata must be well-formed XML. There are one required element ("metadata"), two recommended elements (uniqueid, vendor) and a bunch of optional elements. We don't say anything about unknown elements being allowed or disallowed. Nor do we say anything about element attributes that do not follow the spec. As best as I can remember, during our discussions while we were writing the spec we said that unknown elements or elements that don't follow the defined structure should be ignored by UAs that wish to display this data. Perhaps we should make this more clear in the spec. Tal [1] http://code.typesupply.com/browser/packages/woffTools/trunk/Lib/woffTools/tools/validate.py#L468 to http://code.typesupply.com/browser/packages/woffTools/trunk/Lib/woffTools/tools/validate.py#L1014 [2] I may have it set to be more strict than the spec requires. This is on my list of things to re-examine once we have more concrete agreement on the spec. [3] http://www.w3.org/Submission/2010/SUBM-WOFF-20100408/#appendix-a
Received on Thursday, 20 May 2010 10:42:47 UTC