RE: WOFF and extended metadata

> I agree that nesting capabilities are important, but arbitrary nesting has been objected to by the implementers. 
To be clear, what was being objected to was the implicit expectation that arbitrary XML schemas  - which includes arbitrary tree depths - would be expected to be rendered in a way that is useful, usable and accessible to users, all in the absence of any driving use-case beyond a general requirement of 'extensibility'.  Given that we also wanted the ability to localize such data according to a known pattern, it followed the schema did need definition. 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 - i.e. code that can do the latter in a very visually attractive manner may not be able to do the former at all, the set of possible UI solutions is not the same etc - it's not unreasonable to try and  think of use-cases where arbitrary nesting is beneficial. Assuming it should be made necessary because we can't come up with a use-case today and can't predict all future needs is circular and could justify just about anything e.g. "we don't know whether people may want digital signatures so let's add it in !". For metadata, 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. 

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 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. But until we do have such use-cases and a need to address them, I'd rather not make the perfect be the enemy of the good by complicating the most common cases with patterns meant to address far more specific ones. 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. 

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 :)

Received on Wednesday, 16 June 2010 23:18:36 UTC