Multiple Inheritance

2004-25-04, MED

Right now, LDML documents 'multiple' inheritance, whereby if an element is not found searching all the way up to the root, that a different element chain is accessed. See http://www.unicode.org/reports/tr35/#Multiple_Inheritance

Markus made the suggestion (which I agree with) to instead put the information into the LDML structure, not just in the documentation. I looked at what that would involve, and here is my recommendation.


The current cases are calendars, stand-alone months/days, and currency grouping, decimal, and pattern elements. The idea is to have an item like an alias, but whereas an alias points to the same element in a different locale, this item points to a different element (or element/attribute combination) in the same locale.

The simplest would be for this to be an alias with a special attribute, since we already have provision for alias in lots of points in the DTD. An initial suggestion is:

<alias path={XPATH}/>

where XPATH is defined as in http://www.w3c.org/TR/xpath. See tutorials on:

The additional restriction we would need to add is that the path has to distinguish a single element.

Here are the changes that would be necessary. Notice that I am not well conversant with the ins and outs of XPath, so we would need to check over the paths before implementing this. We also probably want to add [position()=1] to the path (somehow), to force it to be unique.

  1. In the DTD, add path as an attribute to alias.
  2. In root, add for gregorian months and days; and for hebrew, islamic, islamic-civil months

    <dates>
    <calendars>
    <calendar type="gregorian">
    <months>
    <monthContext type='stand-alone'>
    <alias path="../@type='format'"/>
    ...
    <days>
    <dayContext type='stand-alone'>
    <alias path="../@type='format'"/>
    ...
  3. For each non-gregorian calendar that is not represented in root, we would add path aliases for any missing elements. Example, japanese currently has only eras in root:

    ...<calendar type="japanese">
    <eras>...</eras>

    In root add:

    ...<calendar type="japanese">
    <months><alias path="../../@gregorian/months"/><months>
    <days><alias path="../../@gregorian/days"/><days>
    <week><alias path="../../@gregorian/week"/><week>
    <am><alias path="../../@gregorian/am"/><am>
    <pm><alias path="../../@gregorian/pm"/><pm>

    <eras>...</eras>

    <dateFormats><alias path="../../@gregorian/dateFormats"/><dateFormats>
    <timeFormats><alias path="../../@gregorian/timeFormats"/><timeFormats>
    <dateTimeFormats><alias path="../../@gregorian/dateTimeFormats"/><dateTimeFormats>

    Note: as a part of this work, look at the elements in root: if an element is identical to gregorian, eg buddhist dateTimeFormats are the same, then replace by these aliases.
  4. Currencies are harder to handle. They have optional symbol?, pattern?, decimal?, group?. For each currency (eg USD) in each language (eg German), the symbol should default to the display name; the decimal should default to the number decimal, the group should default to the number group, and pattern should default to the standard number currency pattern. So this has the following results:

    For the top level where each currency appears for the first time (usually either root or the language locales), add the following missing elements:

    <currency type=xxx>
    <symbol><alias path="../../@displayName"></symbol>
    <pattern><alias path="../../../../currencyFormats/currencyFormatLength/currencyFormat@type='standard'"></symbol>
    <decimal><alias path="../../../../symbols/decimal"></symbol>
    <group><alias path="../../../../symbols/decimal"></group>

    We would also have to introduce <alias> as a possible element for symbol, pattern, decimal, group.

Issues

  1. Alternatively, we could have path='...' as an attribute on the above elements. That would remove the need for one "../" in the path name, and overloading the alias element.
  2. It is more than a bit ugly to add all the elements to the currency types. That would bulk up the data files quite considerably, and at levels other than the root. And in the root we'd be forced to add all the ISO currency codes. I think in this case it would be better to simply document the behavior.
  3. Some elements are not inherited from their parent locales. For example, all of the elements in a <collation> element are part of the structure of the collation data itself. So everything in a <collation> element is treated as a single lump of data, as far as inheritance is concerned. We should consider a way to handle this also by means of structure rather than documentation.