base direction considerations [I18N]

[aphillips]

(general)
https://cdn.staticaly.com/gh/w3c/wot-thing-description/TD-TAG-review/index.html?env=dev

As discussed in the teleconference, no reference is made to support for bidirectional text values. The I18N WG has recently published a document (string-meta) and has had a number of issues open against other WGs as well as TAG regarding the problem of identifying and conveying the base direction of text in data formats, such as those based on JSON-LD, schema.org, RDF, and so forth.

We do not have a general purpose solution to offer currently. Because your spec is only "notionally" conformant to some of the aforementioned standards, you might be free to adopt some of the suggested designs (notably the Localizable pattern) in our draft. However, that's probably not a good idea, given that standardization work in this area in the (hopefully near term) future might go in a different direction and leave your implementers orphaned. In any case, this is an important problem. We would suggest:

• include a health warning describing the problem (probably by referring to string-meta)
• suggest that producers generate bidi controls or markers as appropriate to try to ensure proper display
• suggest that consumers apply bidi isolation (which they should do anyway) and employ first-strong heuristics in the absence of base direction metadata

[mkovatsc]

We have included new text into the Editors' Draft that is based on string-meta section 4.5 Script subtags:

Identification of the base direction of human-readable text in TDs is based on the following set of rules:

• If no default language tag is given, the base text direction MUST be assumed to be LTR (left-to-right). This implies that if the language used in human readable text uses a script that is written RTL (right-to-left), the default language tag, potentially including a script subtag, needs to be explicitly specified.
• Outside of MultiLanguage instances the base text direction MUST be inferred from the default language tag.
• In cases where a language can be written in more than one script which use different writing directions, the value used for @language MUST include a script subtag so that an appropriate base direction can be inferred.

We chose this approach, as we are partially prevented to use metadata: no direction support in JSON-LD. I will add the "health warning" and reference to string-meta. I hope your other two bullet points are covered by the text cited above.

[takuki]

I added a Note in section 6.3.10 Human-Readable Metadata to give a health warning with a reference to string-meta.

[mkovatsc]

I added the following Note in 5.3.1.1 Thing to address the issues with bidirectional text:

NOTE
Great care has to be given when assigning bidirectional text to the human-readable metadata of Thing Descriptions. Producers of such texts are advised to include bidi controls as appropriate to try to ensure proper display. Consumers of such texts are advised to apply bidi isolation when including human-readable metadata of TDs in other text (e.g., for Web user interface). Strings on the Web: Language and Direction Metadata [string-meta] provides some guidance and illustrates a number of pitfalls when using bidirectional text.

[mmccool]

Feedback from i18n is that we should use "first-strong" as a fallback rather than assuming LTR. I will update that assertion (the case of no language information) to say that upon their recommendation).

[sebastiankb]

Propose to close this issue. The guideline for handling the basic text direction in a TD instance is clearly described in the specification.

@aphillips Please let us know if there is something missing.

[aphillips]

Thanks for the updates. I18N reviewed this in our teleconference of 2019-09-26. A few comments:

• there have been developments in support of base direction in JSON-based formats, notably during TPAC, where JSON-LD agreed to add direction metadata to context in 1.1. Obviously this work is not currently mature, but the direction (no pun intended) has been set. Your WG should consider the implications for current or future revisions.

• the text in 5.3.1.1 is generally okay, although, to be honest, I think we'd prefer if WOT didn't define (and therefore have to maintain) an algorithm for computing base direction. Would it help if we put a "recommended algorithm for determining base direction when direction metadata is not present" in string-meta and you just referenced that?

• the note in section 6.3.2 is okay: it may soon be obsolete, but timing is everything ;-).

[aphillips]

Note: JSON-LD's resolution to add @dir can be found here: w3c/json-ld-syntax#11. This is not a blocker for CR, but might affect your text during the CR period (notably the NOTE in 6.3.2 and possibly instructions on handling the new attribute in the @context and in string literals).

[iherman]

Some pointers in the JSON-LD 1.1 specification:

• JSON-LD 1.1 terms to express base direction

• Two ways to express the JSON-LD terminology in RDF:

  • through a family of datatypes; or
  • through a special rdf:CompoundLiteral class.

  (Users of JSON-LD processors can choose which representation to use when doing an RDF conversion.)

None of the two solutions is perfect, and it is up to the RDF community to see which one would stick (if any). But the solution is clean on the JSON-LD 1.1 level. It is probably a good idea for WoT to align with this.

[sebastiankb]

Thing Description supports the @language for defining the default language. Regarding the multiple-language usage in one instance, we had to go a different way. The reason for that is that Thing Description is a balancing act between JSON-LD and JSON Schema. E.g., we use title from JSON-Schema which, however, do not support an array definition. That is the reason why we introduce titles to provide multiple-language values. E.g.,
https://www.w3.org/TR/wot-thing-description/#example-8

I have the feeling that we cannot harmonize this for TD 1.1. However, we should reconsider this when we define TD 2.0.

[sebastiankb]

close this issue as there is new review on TD 1.1 from the I18N group. Also see
w3c/i18n-request#171