RE: WOFF and extended metadata

My understanding is that Sylvain proposed defining a new element <metadata-extended> that may itself contain arbitrary number of <property> elements, each containing an optional <group> attribute and mandatory <name> and <value> attributes. Implementations would then be able to handle any extended metadata by displaying <name>=<value> pairs, with possible nesting of them using <group>.

E.g. if I add this to my metadata:

</metadata>

<!-- elements defined by the WOFF spec go here, extended by -->

    <metadata-extended>
	<property group="Vendor-specific info" name="Product ID" value="2009-10_OT" />
	<property group="Vendor-specific info" name="Character Set" value="WGL4" />
	<property name="Font Category" value="Brush Script" />
    </metadata-extended>

<!-- This may be followed by an arbitrary metadata added by a font vendor -->

	<blahblah>
		<foo>
			<bar>
				<lalala/>
			</bar>
		</foo>
	</blahblah>

</metadata>

then any compliant implementation will be able to deal with it by simply displaying the following information:

(Standard-compliant metadata is displayed here, followed by extended metadata items)

Vendor-specific info:
   Product ID = 2009-10_OT
   Character Set = WGL4
Font Category = Brush Script

There is no guarantee that arbitrary metadata section will be either parsed or displayed.

Regards,
Vlad


> -----Original Message-----
> From: Tal Leming [mailto:tal@typesupply.com]
> Sent: Thursday, May 27, 2010 3:05 PM
> To: Sylvain Galineau
> Cc: Jonathan Kew; Levantovsky, Vladimir; Christopher Slye; www-
> font@w3.org; public-webfonts-wg@w3.org
> Subject: Re: WOFF and extended metadata
> 
> 
> On May 27, 2010, at 1:54 PM, Sylvain Galineau wrote:
> 
> > I'm not sure what you're saying.
> 
> Honestly, I'm having a hard time following you as well.
> 
> > My proposal defines everything that a
> > browser will render, including an extension point allowing font
> vendors
> > to add their own data to the font info UI. Once I have written
> rendering
> > code for such a format, I *am* done. The metadata we have already
> defined
> > will render. The  conforming metadata you and others add will render
> too.
> > All of it. It will work the same in 10 years as it would next week.
> 
> Okay, so your code would support this abstraction:
> 
> <metadata>
> 	<element attribute="text" />
> 	<element attribute="text">
> 		<childelement attribute="text">
> 			text
> 		</childelement>
> 	</element>
> </metadata>
> 
> This would allow you to support future additions to the spec because
> you are supporting a structure, not a set of defined elements, right?
> What if a future version of the spec adds this element?
> 
> 	<blahblah>
> 		<foo>
> 			<bar>
> 				<lalala/>
> 			</bar>
> 		</foo>
> 	</blahblah>
> 
> Given some of what you said before about nesting, I don't know.
> 
> > What do I do if people don't conform
> > to these guidelines ? Does it mean I'd effectively parse this unknown
> data then
> > check its tree depth and other structural constraints in order to
> figure out whether
> > it'll fit in my UI ? Then what if it doesn't ? Up to me ?
> 
> All of this applies to your proposal as well. We have to answer these
> questions no matter what direction we go in.
> 
> Tal

Received on Thursday, 27 May 2010 20:53:22 UTC