- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 2 Jun 2010 17:45:50 +0000
- To: Jonathan Kew <jonathan@jfkew.plus.com>
- CC: Håkon Wium Lie <howcome@opera.com>, Tal Leming <tal@typesupply.com>, Jonathan Kew <jfkthame@googlemail.com>, "Vladimir Levantovsky" <Vladimir.Levantovsky@monotypeimaging.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
From: Jonathan Kew [mailto:jonathan@jfkew.plus.com] Sent: Wednesday, June 02, 2010 9:28 AM >Is a simple block of plain-text all the "extension" that anyone will ever want? I'm surprised, I thought there was a desire to be able to identify elements within the metadata - and this would include elements within > future/vendor-specific extensions. My personal preference would have been to skip XML entirely until we know we need it and stick to a 'name:value' style format but Tal and others feel that ship has sailed. > Of course, even within Tal's proposal there's nothing to stop the author doing... It's not just that. With the name and value stored in different nodes, we must rely on something else to pair them together and that seems to be the lang attribute. So now we get to define what should happen when the pairing is broken e.g. using Tal's example: <item> <name> <text lang="en">Message</text> <text lang="nl">Bericht</text> <text lang="fr">Message</text> <!-- dangling property with no value --> </name> <value> <text lang="en">Hello!</text> <text lang="nl">Hallo!</text> <text lang="jp">ohayoo</text> <!-- dangling value with no property name --> </value> </item> One option is to show the French 'Message' with no value; another is to ignore it; yet another is be very strict and treat the entire item as invalid. A reasonable compromise is to show property names even when we can't find a matching value but ignore dangling values with no property name. Such ambiguity and its resolution should not imo be an unavoidable feature of a metadata name-value pair format. But we implicitly have it here and we'll have to specify how it's handled. Thus I propose that the metadata block accept multiple documents to keep orthogonal concerns such as extensibility and localization orthogonal: <metadata lang="en"> ... <ext> <group name="foo"> <property name="bar">value</property> </group> </ext> </metadata> <metadata lang="fr"> ... <ext> <group name="fou"> <property name="barre">valeur</property> </group> </ext> </metadata> i.e. no more text element whose sole purpose is to tag things with a language value, no need to worry about dangling issues: a property either has a value or none and gets displayed either way. The whole thing still feels overly heavy to me but I'd find it easier to understand, explain and even process - find the document that best fits the user's language preference then render it all - than a structure where some elements exist only for localization, the language attribute is also a binding identifier in some cases, and this is what you do when the binding is broken this way, that way etc. I'd rather pay the price of repeating markup text that will be highly compressed anyway if it avoids the brittleness and nagging constraint enforcement that will come with a single document that does it all.
Received on Wednesday, 2 June 2010 17:46:30 UTC