Re: WOFF and extended metadata

On 27 May 2010, at 00:43, Sylvain Galineau wrote:

>> I'm assuming all current browsers that might implement such a feature
>> already have XSLT processing facilities, and can display a simple panel
>> containing the tiny subset of HTML that this generates. As such, the
>> cost of implementing this should be minimal: extract the XML metadata;
>> call an existing function to apply an XSL transform to it; call another
>> existing function to display the resulting HTML in a UI widget.
> 
> And if I don't want to use XSLT ? And if I don't want to use HTML to
> render this ? What happened to not creating specific UI requirements ?

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.

> Why does the input for font metadata have to be open-ended and 
> arbitrarily complex ?

It doesn't; but it does seem useful to provide at least one or two levels of nesting, to allow some grouping structure; and it also seems useful to support localizable content for some elements of the metadata. 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.

> I'm of the opinion this stuff should be parsable by a Perl or Python script without
> any XML parser dependency but that ship has apparently sailed. I'm fine with that. 
> I am not fine with saying that because this is XML then we can also depend on XSLT
> to make HTML and therefore everything is great.

I'm not calling for a required dependency on XSLT and HTML, just suggesting it as one simple route to implementation. 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, I expect handling malformed input reliably and consistently may be a bigger headache. Personally, I'd rather use a small XSLT transform, but you may choose differently.

JK

Received on Thursday, 27 May 2010 13:12:47 UTC