This proposal is part of the 2.03 upgrade process, please comment by replying below.

Standard
Activity and Organisation

Schema Object
All uses of @xml:lang attribute

Type of Change
Change Definition

Issue
Xml:lang references the generic XML spec which allows for a range of languages, locales, regions and scripts. It is used in our schema with a more limiting definition - specifying sole use of ISO 639-1. This is not enforceable. Moreover, there are users who need to specify languages that aren’t on the ISO 639-1 list, but can be specified with BCP 47.

Proposal
Change all definitions of xml:lang

  • From ISO 639-1 code specifying the language of text in this element.
  • To A code specifying the language of text in this element.It is recommended that wherever possible only codes from ISO 639-1 are used.

Standards Day
Accepted

Links

 

Comments (9)

IATI Technical Team
IATI Technical Team

There will be some consultation calls in early July for any 2.03 proposals where people would like to discuss them further - if you would like to discuss this proposal on one of the calls please ‘Like’ this IATI tech team post by end of Mon 26 June - you can do this by clicking the heart symbol to the bottom right hand side of this message.

Further details on the calls are available in the ‘How to participate’ topic.

IATI Technical Team
IATI Technical Team

This proposal will be discussed on a consultation call on Tuesday 4 July, 3pm (BST), 1 hour

To join this call, use this link from your computer, tablet or smartphone https://global.gotomeeting.com/join/760173485
You can also dial in using your phone
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129
Access Code: 760-173-485

Please 'like' this post if you plan on joining this call (click the heart symbol to the bottom right of this message)

IATI Technical Team
IATI Technical Team

Notes from consultation calls w/c 3rd July

The proposal was reviewed by those on the call and there was no objection from the group.

Hayden Field
Hayden Field

Petya Kangalova has noted that Codelists have a boolean complete attribute which impacts usage in a way relevant to this proposal.

The documentation on this attribute is:

Some codelists, such as the ISO country codes, are not ‘complete’ lists of all possible values that might be used. In the case of countries, publishers may use extra user defined codes (such as ‘XK’ for Kosovo) or valid historical values that are not on our maintained list.

For other codelists, such as the DescriptionType codelist, if the value is not on the codelist the data doesn’t make any sense - it is invalid. This is an example of a ‘complete’ codelist.

We distinguish between these two types of codelists by the use of an xml attribute: complete="1"

and

complete - boolean that describes whether the codelist is ‘complete’ ie. having a value not on the codelist is definitely invalid. An example of an incomplete codelist is country codes, where extra codes may exist for disputed countries.

Reading through this, it appears that:

  • complete="1" - use of values from this Codelist is mandatory - using other values makes the data invalid
  • complete="0" - use of values from this Codelist is recommended, though using other values is absolutely fine (but might lead to a warning in a validation tool)

The Language Codelist is marked as complete="0". As such, this proposal appears redundant in its current state.

An alternative course of action would be to improve documentation around the complete attribute.

Andy Lulham
Andy Lulham

This change makes the xml:lang definition consistent with the fact the language codelist is complete="0". So I don’t see it as redundant.

That said, this isn’t my proposal and I have no strong feelings either way.

Hayden Field
Hayden Field

So it does… redundant probably isn’t the best term.

Looking at this again, there are currently multiple definitions for valid values within the xml:lang attribute:

  1. ISO 639-1 code (from the attribute definition)
  2. A value on the Language codelist (auto-generated documentation)
  3. Any value, recommended that it is on the Language Codelist (Codelist documentation)
  4. Any valid BCP 47 value (XML spec)

Looking at how these interact…

  • Points 1, 2 and 3 are part of the IATI Standard.
  • Point 4 is part of a standard that IATI builds upon.
  • Points 1 and 2 are stricter than Point 3.
  • Point 4 restricts the values permitted by Point 3.

At present, there is no documented manner in which contradictions within the IATI Standard should be resolved. I would premise that the more permissive of valid interpretations of the contradicting statements be deemed the correct interpretation of the IATI Standard.

Based on the above, this proposal does not need to go through the 2.03 upgrade process, and should instead be implemented as a backwards-compatible bug fix.

Separately, the auto-generated documentation stating presence on Codelists should be fixed to take into account the complete attribute.


Please log in or sign up to comment.