Re: More comments on WOFF metadata

On Wednesday, November 24, 2010, 9:43:57 PM, Tal wrote:

TL> On Nov 19, 2010, at 12:44 PM, Christopher Slye wrote:

>> Comments from my colleague Eric Muller. Apologies if some of this has been debated and resolved; better safe than sorry:

>>> 1. all the WOFF elements should be in a namespace. This would address the problem raised by Laurence Penney, and is vastly preferable, IMHO, to a doctype declaration (see the philosophy of RELAX NG for the reasons)

TL> and

>>> 3. Once you have a namespace machinery, extensibility is typically provided by allowing elements of a different namespace. This also solves neatly the problem of multiple sources contributing to the extension, without having to install a registry.

>>> 4. I suspect that the type xsd:NCName is too constraining for lang attributes, which ought to allow BCP47 names.

TL> Would adding these requirements make existing files invalid?

Number 1 would make existing files invalid. 

Number 2 would only affect new files which used that extensibility mechanism; however it would require changes in the WOFF spec regarding what was valid and what UAs should accept or reject.

Number 3 would not make exiting files invalid, and indeed is a desirable change. It was not the intention to exclude BCP-47 names.

>>> 2. since the intention of the metadata is primarily to be presented to humans, localizability and accessibility seem important.

>>> 2.1 On the localizability side, I would have expected that an element like <description> would allow multiple <text> elements, each with different lang attributes.

TL> This is already in the spec.

Agreed, its is.

The fact that we got this comment, however, implies that it is not clear, and in particular, that the wording

"Such localizable elements are indicated by the statement "This element may be localized" in the description below; the internal structure of text elements with lang attributes is not repeated for each element type."

was missed. On the other hand, that capability is referred to later in the comment so i am not sure that it was missed.

>>> 2.3 on the accessibility side, because metadata often contain names (e.g. credits/credit/@name), a plain text value is generally not enough. The common practice is to allow structured text, and in particular to support pronunciation and sorting metadata (which would be meta-metadata in this case).

TL> Structured text has been discussed several times and it was
TL> decided that it is a can of worms that we want to avoid. This should be in the list archive.

>>> 5. Licenses are not just translations of a text in different languages, they are also adaptations to local laws. I think this implies that the url and id attributes should instead be on the various <text> elements inside <license>.

TL> Hm. The URL that the license element is directing the user to could handle this, no?

It *could*, if the server is set up to do content negotiation based on user language.

However, it does not seem at all far fetched that there could be, say, English and french and Japanese versions of a license, each with a distinct URL and somewhat different contents (content, not just language); so the ability to add @url to the localised text elements would be a useful addition.

That change would not break existing content.

TL> This last point brings up a change that we may need to make to
TL> the spec. We say that "at least one text subelement MUST be
TL> present" in elements that can be localized. In the case of the
TL> license we may want to make an exception. There could be no text
TL> elements there since the URL attribute could be doing all of the work.

Good point.



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Wednesday, 24 November 2010 21:21:54 UTC