- 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:09 UTC