Re: WOFF and extended metadata

On 21 Jun 2010, at 19:14, Laurence Penney wrote:

> On 20 Jun 2010, at 11:00, Chris Lilley wrote:
>> On Sunday, June 20, 2010, 12:48:04 AM, Laurence wrote:
>> 
>> LP> Liam,
>> 
>> LP> Are you saying you support, in principle, the idea of a vast and
>> LP> complex raw XML document (ok, maybe without the <?xml ... ?>) as the value of a key-value pair?
>> 
>> No, he is saying he does *not* support the idea of a vast and complex and obfuscated XML document as the value of an attribute :)
> 
> 
> To bring up a real use case:
> 
> Let's say that some time hence, because of widespread badly-formed webfont deployment, it becomes desirable to bundle a small example XHTML file, or XHTML fragment, in the metadata showing how to write webfont code, intending for this code to be used as a template by HTML editors such as Dreamweaver, or to help WordPress blogs with webfonts.
> 
> We use the key "sample-xhtml".
> 
> Should the value be entity-encoded or not?
> 


I find it hard to imagine that embedding such a thing in each downloaded font would be a desirable deployment mechanism. Rather, the vendors (designers, developers, whatever...) offering web fonts ought to be offering boilerplate XHTML/CSS *alongside* the deployable font file itself, as part of the overall package provided to customers. But leaving that aside....

This sounds to me like something that goes way beyond what people would reasonably expect to express in a generic key-value pair metadata form. Also, to be widely useful, it ought to be given a standard, defined place in the metadata spec. As such, it could easily be defined (e.g., in WOFF metadata version 2.0) as a new <sample-xhtml> element that directly includes the relevant XHTML fragment. This is NOT what the key-value metadata extension mechanism is intended for, and we wouldn't want UAs cluttering their "Show Font Info" panel with it anyway.

JK

Received on Monday, 21 June 2010 18:45:51 UTC