W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2011

some comments on API for Media Resources...

From: Phillips, Addison <addison@lab126.com>
Date: Tue, 12 Jul 2011 12:34:37 -0700
To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <131F80DEA635F044946897AFDA9AC3476A9439FCD5@EX-SEA31-D.ant.amazon.com>
Following are some comments from reading:


1. Section 4.2.1 says in part:

This argument allows to identify the language of the metadata. Values for the metadata will only be returned if it is available in the specified language. Recommended best practice is to use BCP 47 [BCP47]. This parameter is optional.

This doesn't sound like a good design. To have partial metadata returned because some is not localized seems problematic. Similarly, there is no reference to what the phrase "if it is available in the specified language" means. I would suggest that the text recommend that metadata be returned that matches the requested language according to the BCP 47 Lookup algorithm.

2. Section 4.2.3 (example). I don't see any support mentioned in the document for a direction for metadata returned. It would be useful to be able to indicate base direction (such as 'rtl', 'ltr') in order to set the base direction of metadata values for display purposes.

3. Section 4.4.1 defines 'value' as:

This attribute must be filled with an printable string representation.

Notice the editorial nit (an -> a).

I'm not sure what "printable string representation" is supposed to mean. My concern is with the "printable" part: can that be closely defined?

4. Section defines a 'title' attribute. The fields 'titleLabel' and 'typeLabel' are said to hold a "plain string". I believe this is intended to be human-readable natural language in most cases. Thus, they should have associated 'language' and 'direction' attributes.

5. Section recommends using BCP 47 for the values of 'language' and explicitly allows values to be filtered based on this attribute. It is unclear what this means?

6. (same section) There are no examples of what 'languageLink' is used for or what format it takes. Why is this here? I have no idea what one would look like nor why I would want one.

7. Section has fields 'contributorLabel' and 'roleLabel' for which I would have the same comments as (#4) above.

8. (same section) Personal names are given in the example for a single-string field 'contributorLabel'. However, personal names and contributor names really need more structure to be well internationalized. It is difficult to sort a list of items by "author" if one needs to find the family name---and then has to deal with unusual "names" such as "Editors of the New York Times" on top of that. More structure would be useful here.

9. Same comments on Section (Creator)

10. Section is 'MADate', which contains date/timestamp values. Perhaps a reference to our WG-Note on time zones would be useful here, since most values here are likely to be floating dates--and some explicitly are not.

11. Section defines 'keyword'. Keywords may differ by language or culture and thus it would be useful to allow separate sets to be identified.

12. Section The 'format' does not specify whether charset is permitted (e.g. text/xml;charset=UTF-8). Should there be a separate optional charset parameter here?

13. No non-ASCII examples are used. No non-English examples are used. It would be useful to see some alternate languages provided in examples (so one might see how filtering is done).

General observations:

1. I quit making the language/direction comment on text-bearing fields at some point, but it applies to any human-facing text the API returns.

2. There is no provision for selection by market or jurisdiction? Are regional variations, rights, etc. interesting here?

3. The document uses URI globally but I do not see any reference to these being IRIs. Shouldn't they be IRIs?

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 12 July 2011 19:35:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:01:49 UTC