Text base direction again — but now with a solution:-)

[iherman]

The issue of base direction has been plagued us for a while (see also issue 354 on wpub), but we may have a proper solution for it now. There has been discussions elsewhere to look for a solution, a (failed) attempt to revive the discussion in RDF land and, finally, a breakout session at TPAC. This led the JSON-LD WG to re-open the issue of adding base direction to JSON-LD 1.1. On its F2F meeting at TPAC, the JSON-LD WG has accepted a series of resolutions, see the minutes of Thursday and Friday for the details.

The essence is: JSON-LD 1.1 will introduce a new keyword @direction that can be used, essentially, the same way as @language: can be part of the context to denote a global (ie, default) value, and can also be used as part of an individual literal. In our terminology, a LocalizableString in our manifest can have a directional value, if needed, just the same way as we handle language tags.

What I propose is to make changes on the manifest specification to adopt this feature. What it would mean for the manifest is:

• the current direction term disappears and is replaced by a @direction keyword usage alongside @language (see 2.5.1)
• item specific settings (in 2.5.2) will include @direction
• The definition of LocalizableString will be updated
• Some additions to the context file to empower all this.

The result, I believe, would be a much cleaner format for our manifest, and we can but this issue at rest at last.

There is one caveat, though. This is a JSON-LD 1.1 feature, i.e., we become dependent on JSON-LD 1.1. This, by itself, is not a problem, JSON-LD 1.1 is slightly ahead of use in its advance towards a Rec. However, we have to be careful to use this feature in a way that it does not upset JSON-LD 1.0 processors that are supposed to simply ignore an unknown keyword. Without going into details what this means that we should not create the direction alias for @direction, as we do for, e.g., @language and @value. As a consequence, I would propose that we remove the usage of these aliases, and we use @langauge and @value; otherwise it looks very inconsistent.

As soon as the JSON-LD 1.1 editor's draft includes the new feature, I will put in a PR to adopt these changes in the manifest document. We can decide, through the PR, whether we agree with these changes.

(This should supersede, ie, close, issue #39, and also make the discussions in w3c/wpub#354 moot. Finally, it should close the gap in the i18n review in #38.)

Cc: @r12a @aphillips @mattgarrish @wareid @BigBlueHat @laudrain @llemeurfr @GarthConboy @rdeltour @dauwhe

[iherman]

For the RDF inclined among you the question may be what RDF statements are generated for this feature. The JSON-LD WG Meeting minutes' section may provide the necessary answers for now (before the publication of the new ed draft).

[iherman]

It would be nice to have a real-life example in the document. Have anybody such an example that I could use? Ie, a title that has possible directional issues and that should have an explicit base direction assigned.

@BigBlueHat you referred to scientific articles in Hebrew or Arabic that mix their script with latin scientific terms...

@r12a any idea?

[r12a]

In our string-meta doc we use the following example, which i believe is a real book found by Addison. Strip the markup and you should have something useful.

"title": "<span lang='ar' dir='rtl'>HTML و CSS: تصميم و إنشاء مواقع الويب</span>",

When displayed, this should look like this (read it right-to-left) (i couldn't figure out how to right-align it). Note that the 4 directional runs are in reversed order in the example vs expected display.
HTML و CSS: تصميم و إنشاء مواقع الويب

To help with cut & paste and to see the sequence of characters, follow this link to UniView.

Does that work?

[iherman]

@r12a thanks! I have not yet started the PR, but that should work.

Just to use it as a common example with multilingual title, what would be the title in English (or French)?

Thanks!

[r12a]

@aphillips may be able to locate an 'official' translation, but it's something along the lines of "HTML and CSS: Web design and creation".

[aphillips]

From the string-meta source:

<!--
 Title below is actually "HTML and CSS: Design and Build Websites"
 ASIN: 1118871642
 ISBN-13: 978-1118871645
 ISBN-10: 1118871642
-->

[iherman]

This issue was discussed in a meeting.

• RESOLVED: ivan to merge direction PR

View the transcript

Directionality
Wendy Reid: #75
Wendy Reid: first issue is about directionality
Ivan Herman: See Pull request for directionality
Ivan Herman: I have already reported that this whole direction issue now has a clear solution
… I’ve made a PR
… you can do direction much like you can do language
… with the same syntax, either globally or for a given member
… so the PR fixes all the bits
… there is one issue which I put into the document
… having direction in the system means that we have a dependency on JSON LD 1.1
… which is running in parallel with our spec; they plan CR at the same time, they have implementations.
… so they may be ahead of us
… but if you want to run a manifest through a JSON-LD processor that only supports 1.0 you will get errors
… so I created a separate context file that doesn’t have direction
… and made an appendix in the doc
… so you can use this context if you don’t need direction, and need to use a JSON-LD 1.0 processor
… so the question to the group is that it’s OK to keep this as an appendix in the document
… or put it somewhere else, or not do it at all and depend on JSON-LD 1.1
… so I want help from the group in deciding what to do
Wendy Reid: any questions?
Brady Duga: I don’t have strong feelings, but it does feel strange to put in the spec itself
… most things that process this won’t be JSON-LD processors
… but I’m not against it
… I think it should be in a read me or impl guide
Matt Garrish: I’m concerned about how this might be interpreted
… changing our context which is required seems weird
… it could add confusion to have an alternate context
Ivan Herman: I put it there without being convinced it’s a good idea
… I’m fine removing it
… so where would this information go?
… we could give it to the testing people and have this added to information about testing
Matt Garrish: I would put in our wiki for implementation details, so it’s discoverable
Wendy Reid: a wiki is good
Dave Cramer: This seems like it would be a helpful note in the spec itself, if this language property is used, mention that JSON-LD 1.1 is required
… it’s a good use of non-normative text
Ivan Herman: any other comments?
… one comment… for those of you who have been looking at this
… if you look at this example
… it is a good example there for real cases where base direction is necessary
… some people were wondering if this stuff was necessary
… We found a book with a title in arabic and english
Ivan Herman: so it’s good to have a real-world example
Matt Garrish: I think it’s useful to have direction; we have it in EPUB.
Ivan Herman: is there a consensus to merge?
Matt Garrish: +1
Wendy Reid: +1
Brady Duga: +1
Dave Cramer: +1
Gregorio Pellegrino: +1
Ivan Herman: we should also pledge to never talk about direction again :)
Resolution #2: ivan to merge direction PR