MODS language code usage…

With regard to MODS 3.8 documentation viewable here: https://www.loc.gov/standards/mods/userguide/attributes.html#lang

The current documentation states the following:

xml:lang
@xml:lang serves the same purpose as @lang, but follows the W3C documentation that indicates using the IANA language subtag registry, which includes codes from the ISO language and script standards.

This is confusing (and my recommendation is a revision similar to what I provide below).

Reason for confusion: The current documentation can be read to indicate that the IANA language subtag registry is used with the xml:lang attribute. This is really a mischaracterization of the XML/w3c specification. The w3c XML specification specifically states to use BCP-47 valid tags which provides a whole host of other valid tags than just the tags found in the IANA language subtag registry. Rather than pointing MODS users directly to the IANA registry, the more useful thing would be to point them to the BCP-47 documentation. It is not until one reads the BCP-47 documentation that one finds that the IANA language subtag registry is a valid option for use, but more importantly BCP-47 explains how to use the IANA language subtag registry in a valid way. BCP-47 also explains how to use the other components of the BCP-47 recommendation which may be beneficial to understanding some of the tags in the IANA language subtag registry.

Link to BCP-47: https://www.rfc-editor.org/info/bcp47

Suggested rewording: @xml:lang serves the same purpose as @lang, but follows the W3C documentation that requires using IETF BCP-47 compliant language tags. IETF BCP-47 provides instruction on how to construct valid tags for this field. BCP-47 draws upon ISO 639-1, ISO 639-2, ISO 639-3, ISO 639-5, ISO 3166-1, UN M.49, ISO 15924, and IANA language subtag registry.

Then in another section:

Page: https://loc.gov/standards/mods/userguide/language.html#languageterm
In the below replicated example found on the page linked to above, there is a logical error, rendering the example invalid. Providing invalid examples (with out marking them) in educational materials is problematic.
RFC5646 is the current instantiation of BCP-47. BCP-47 is the stable identifier, while the underlying RFC documents can change. Currently BCP-47 and RFC5646 are mostly the same thing, and for the purpose of this post are the same thing. So, in the below example the data provider is saying that they are providing a valid RFC5646 language tag. However, "i-navajo" is not a valid tag. It is not that it can't be found in the IANA subtag registry, rather it is that the subtag registry says that the value has been deprecated in favor of the ISO 639-1 value "nv". Therefore, the RFC5646 valid code for Navajo is "nv". Supporting documentation is provided below. I can also be available for further consultation to the MODS editors. I sit on the IANA mailing list, and am one of the US appointed observers to the ISO 639 workgroup.

Supporting document 1: https://www.iana.org/assignments/lang-tag-apps/i-navajo
Supporting document 2: https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

This resource contains text in Navajo:

< language >
< languageTerm type="code" authority="rfc5646">i-navajo< / languageTerm>
< / language>

BCP-47 and sign languages

For the purposes of tagging language resources By language, when a language code for a sign language is used is the default assumption that the language resource is in the visual/video modality, rather than the textual format? Or is BCP-47 agnostic to these assumptions of modality? For the purposes of ANIA repository of tags, is there a specified suffix for the written modality of sign languages?

What is the case for Brail? Is there a script tag for brail? (Yes there is). But the orthographic representation in brail is still ambiguous.