RE: WOFF and extended metadata

> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
> request@w3.org] On Behalf Of Jonathan Kew
> Sent: Thursday, May 27, 2010 6:12 AM


> I'm not trying to create any specific UI requirements. Whether you (or
> we or any other developers) choose to use that particular approach is
> entirely up to the developers concerned. If you'd rather write a Python
> script that generates RTF to put in a display widget, or C# code that
> uses WPF to draw everything, or some entirely different approach, fine.
> I was just pointing out that at least one low-cost approach to
> implementation seems to be open to us.

The existence of any low-cost approach does not establish that open-ended
XML input is a necessary or desirable feature for the purpose of font 
metadata. Just because anyone can write a 10 line script that displays the
two samples they wrote on their command-line, or a 30-line one that generates 
boilerplate HTML does *not* prove this should be a requirement.

Are we trying to specify a simple extensible metadata format for a font container ? 
Or some kind of generic XML-based document format that each browser must invent a 
rendering for ? Why is it such a burden to scope this ? Why is it so bad to ask
that users of the format demand the capability and present real use-cases before
we allow this ?

> It doesn't; but it does seem useful to provide at least one or two
> levels of nesting, to allow some grouping structure; ...

You already have that. It's trivial to do in the extended section if
we need one.

>...and it also seems
> useful to support localizable content for some elements of the metadata.

That's fine as well. We can use the same lang attribute throughout. Btw,
what if the arbitrary XML the font vendor injects does not use the same
attribute name to indicate language ? How will you detect that ?

> I would suggest that the current schema represents this in a pretty
> simple, easy-to-understand way, AND that we could allow it to be
> extended *following the same pattern* without it becoming burdensome
> for browsers to present the information to users through a general UI.

Defining an extension pattern is all I'm asking for. 'Anything goes as
long as you think it looks like what we've defined' is neither a pattern
nor a specification, and it can't be tested for conformance.
 
> I'm not calling for a required dependency on XSLT and HTML, just
> suggesting it as one simple route to implementation. 

I find XSLT overkill for something as structurally simple as metadata.
That using it constitutes a 'simple' route to display it is a strong 
clue there is something overly complex with the approach and that we 
are aiming well beyond metadata. Another way to describe it is feature 
creep.

> Feel free to take another. I don't think it would take much effort to 
> write a Perl or Python script that does something equivalent, for example; 
> though if you don't use an existing parser module,...

If it's going to be XML, no point in not taking that dependency. I was thinking
of something with no XML at all, like the manifest or configuration files Unix 
programs have parsed for decades. Metadata has never needed XML to be expressed,
parsed and extended simply and reliably. But if we've made that serialization choice 
and already published font that use it already, then by all means let's be 
pragmatic and leave that untouched.  

It just doesn't follow we *have* to allow the insertion of just about any other XML 
in it. Or that it's desirable simply because someone wrote a recursive script that 
renders it somehow.

Received on Thursday, 27 May 2010 15:07:30 UTC