- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Fri, 18 Jun 2010 12:15:18 -0400
- To: Sylvain Galineau <sylvaing@microsoft.com>, Laurence Penney <lorp@lorp.org>
- CC: Tal Leming <tal@typesupply.com>, Erik van Blokland <erik@letterror.com>, "www-font@w3.org" <www-font@w3.org>, 3668 FONT <public-webfonts-wg@w3.org>
On Wednesday, June 16, 2010 7:18 PM Sylvain Galineau wrote: > > And if we're defining the > schema then we can certainly allow nesting if it is useful. It can be > arbitrarily deep; but if one accepts that the requirement to render > arbitrarily deep data trees is not equivalent to rendering data of a > known depth to those doing that rendering ... > <snip/> > ... I personally think it's OK for UAs to assume a relatively > limited depth in designing their UI if they so choose i.e. it should be > up to the browser as to whether they want to support 'infinite' depth > or, say, up to 8. > I agree. > Fwiw, Laurence's non-XML key-value pair scheme is something I would > originally have expected to be sufficient. An XML equivalent, wrapped > by language-tagged container, seems reasonable. I am comfortable having > each property element specify both a name and a value through > attributes, with nested properties if need be. It sounds like we have the grounds for consensus here - in this particular case I personally do not have a strong preference in "attributes vs. elements" debate, and attributes can easily be used to define the key/value pairs. > It has been pointed out > that in some cases the value might need its own markup e.g. Ruby > annotation for Japanese Kanji in which case attributes are undesirable. > <snip/> > I understand why HTML and CSS need to address Ruby and I like > that they attempt to. But they're not simple metadata formats meant to > describe a specific resource type. > Agree. > This, however, is not a web page, it's font metadata. If something > cannot be described in it that would be better done using a capable > document format with styling capabilities such as HTML+CSS then use the > metadata to include a descriptive link to a page with the information. > We are talking about browsers here, after all. Following links is not > unnatural :) > So, to recap what's just been said - we seem to agree that the following metadata structure with extension mechanism and agreed upon, finite nesting depth (e.g. up to 8) would be an acceptable solution (where [...] indicates an implied attribute): <metadata> <!-- elements already defined by the WOFF spec go here --> <extension [lang="tag"]> <item [lang="tag"] name="group_name" value="group_value"> <item [lang="tag"] name="property_name1" value="property_value1"/> <item [lang="tag"] name="property_name2" value="property_value2"/> <!-- where any of the items, if needed, could be --> <item name="URL" value="http://link.to.external.doc"/> <!-- that provides additional info for a user --> </item> </extension> <extension [lang="tag"]> ... </extension> </metadata> If this is the case, I would like to ask all WG members to state their position on this proposed structure to see if we have a consensus. Thank you and regards, Vlad
Received on Friday, 18 June 2010 16:17:07 UTC