Re: WOFF and extended metadata

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.

<uniqueid>
 <metadata/>
</uniqueid>

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