Internationalization Self-Review for Controller Documents v1.0

[msporny]

This issue contains the Verifiable Credentials Working Group's internationalization self-review of Controller Documents v1.0, which are a generalization of DID Documents and some content from VC Data Integrity. All this to say, horizontal review has occurred for most of this content before when it was in DID Core, and then again when it was in Verifiable Credential Data Integrity. The Working Group recently decided that it would rather have this content in a separate specification than embed it in DID Core or VC Data Integrity, and that specification is Controller Documents v1.0.

1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc), ensure that there’s metadata about and support for basic things such as language and text direction. Also check the detailed guidance for Language and Text direction.

• Not applicable

The specification publishes cryptographic material and thus does not contain text that will be read by a human being. The one exception for this is possibly software developers, who might see error messages, which have specific codes, which are internationalizable, but whose internationalization characteristics are up to each implementer.

2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics. take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) Also check the detailed guidance for Typographic support.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc. make allowances for the ways different scripts handle units of text. Also check the detailed guidance for Text-processing.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers understand the implications of normalisation, case folding, etc. Also check the detailed guidance for Text-processing.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

5. If the spec (or its implementation) sorts text ensure that it does so in locally relevant ways. Also check the detailed guidance for Text-processing.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

6. If the spec (or its implementation) captures user input ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. Also check the detailed guidance for Local dates, times and formats.

• Not applicable

Dates and times are used when expressing the revocation of cryptographic material. For these fields, we use XML Schema 1.1 date-time format and provide guidance in the specification on how to display dates and times that are sensitive to locale preferences.

8. If the spec (or its implementation) allows any character encoding other than UTF-8. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct. Also check the detailed guidance for Characters.

• Not applicable

All character encoding uses UTF-8.

9. If the spec (or its implementation) defines markup ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements. Also check the detailed guidance for Markup & syntax.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc. Also check the detailed guidance for Local dates, times and formats.

• Not applicable

Dates and times are used when expressing the revocation of cryptographic material. For these fields, we use XML Schema 1.1 date-time format and provide guidance in the specification on how to display dates and times that are sensitive to locale preferences. The specification publishes cryptographic material and thus do not provide features for expressing names, addresses, or other fields that have internationalization considerations.

11. If the spec (or its implementation) describes a format or data that is likely to need localization. ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc.

• Not applicable

The specification publishes cryptographic material and thus does not provide the features described in the paragraph above.

12. If the spec (or its implementation) makes any reference to or relies on any cultural norms ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).

• Not applicable

Dates and times are used when expressing the revocation of cryptographic material. For these fields, we use XML Schema 1.1 date-time format and provide guidance in the specification on how to display dates and times that are sensitive to cultural and locale preferences.

[selfissued]

What is the workflow that this self-review is subject to?

[msporny]

What is the workflow that this self-review is subject to?

It is a review that someone in the WG performs and the WG reviews and approves (and can modify over time). The Privacy and Security groups then take it as input to determine if they agree with the self review (as they perform a critical review of their own).

You can read more about the process here:

https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review