Comments (12)
See #1448
from vc-data-model.
#1446 has been raised; this issue may be closed if that PR is merged.
from vc-data-model.
I disagree. When the Arabic string is inserted in another context, it wants to be bidi isolated. Doing that means setting the base direction for the string. If there is no base direction stored in the record, the consumer has to figure out (by inspecting the string or from the language tag) which string direction to use--or depend on auto
, if that is an option in the target context. auto
is an option in HTML, but many UI APIs (Windows, MacOS, Java, etc.) require a specific direction.
LTR is the default for most applications and most languages, so omitting the @direction
from left-to-right en
and fr
texts isn't a serious disadvantage to those strings. But it's a good idea to always transmit RTL text with an RTL direction. It is the case that purely Arabic strings will work appropriately with auto
, so I don't disagree with @iherman's observation. But most applications don't have humans evaluating each string for whether the direction is needed or not.
from vc-data-model.
I see what you mean, @aphillips. To be honest, my observation comes from the fact that, by keeping what is there, we might be accused of a bias, i.e., by being unnecessarily discriminating for a particular language. In this day and age, this is not an impossible reaction.
(Note that a VC is not really meant for human inspection, it is mostly for machine processing. Ie, inspecting the string for unicode characteristics or a language tag is really an issue if that counts.)
from vc-data-model.
Omitting these direction attributes may be technically fine, but doing so removes the demonstration meant to be conveyed by these examples. I would be fine with a comment in the text that says something like, "These direction attributes are not technically required for these single-language strings; they are included here for clarity of demonstration, and to make copy+paste+edit deliver functional results."
from vc-data-model.
Omitting these direction attributes may be technically fine, but doing so removes the demonstration meant to be conveyed by these examples. I would be fine with a comment in the text that says something like, "These direction attributes are not technically required for these single-language strings; they are included here for clarity of demonstration, and to make copy+paste+edit deliver functional results."
I like this proposal. Under the motto "no good deed goes unpunished", could you submit a separate PR, @TallTed ? We could then close #1446
from vc-data-model.
IMO, the string fields don't need to be individually marked with
direction where two cases apply:
- resource-wide metadata has been set (eg. at the top of the file) indicating the default direction for all strings AND that direction applies to the individual string's content (if not, eg. if the resource-wide direction is set to RTL but a particular string has an overall direction of LTR, then it needs to be labelled).
- no resource-wide metadata is set AND the specification requires that a receiving application must apply strong-first analysis to a string AND the string doesn't start with the wrong type of strong character.
If the specification doesn't require the use of strong-first analysis by the receiving application, and there is no resource-wide default to fall back on, then each string would need to be individually labelled.
from vc-data-model.
@TallTed i think your edit should say that the direction is not required for this particular case because... (presumably the application is expected to do first-strong analysis and get it right). It's not that these are just optional in all cases. Or better still, you could include some strings that are ambiguous (ie. don't resolve correctly via first-strong analysis) – the i18n WG may be able to provide you with examples.
Also, you moved a period to the left of some Arabic text. This is one of the problems with trying to create RTL examples. It now looks as if the RTL base direction has been applied to the text for that string in the example, although in fact it hasn't - which will become clear if someone tries to copy the Arabic text in that example to use someplace else (the period will end up in the wrong place if direction is applied to the string, either explicitly or by the surrounding context). There's no easy answer here (see https://www.w3.org/International/questions/qa-bidi-source.en.html).
Personally, i'd be inclined to leave the period where it was, and perhaps indicate that the Arabic examples show the in-memory order. (Fwiw, if you had a string containing <arabic-text><latin-text><arabic-text>
this problem would be significantly increased, because directional runs would look out of order (making it difficult to read).
from vc-data-model.
@r12a —
If the specification doesn't require the use of strong-first analysis by the receiving application, and there is no resource-wide default to fall back on, then each string would need to be individually labelled.
So far as I know, our specs don't require the use of strong-first analysis by the receiving application. Also, there is no resource-wide default to fall back on. So, as you say, and as I've done, each string needs to be individually labelled.
Although, the advice we've received from @aphillips is that any string that is entirely composed of characters that include their own directionality, and which are all the same direction, does not require the individual labelling ... hence the text I inserted.
Note also that we've also received advice about "string[s] containing <arabic-text><latin-text><arabic-text>
" or other mixes of ltr and rtl characters in other areas of this current work.
It's incredibly frustrating and time consuming for us non-I18N experts to be receiving, and using trial-and-error to apply, contrasting advice from different people in the I18N group(s). It seems that maybe the I18N people who are now scrutinizing the work of the VCWG should get together, get on the same page about the advice to be issued to us, and issue it as explicit change requests/suggestions, so we're not re-re-re-composing our text based on periodically differing advisories.
The net effect of this and related threads on me, is that I want to remove any hint of the rtl text — which we added at I18N prompting! — from our documents, because I can see no relatively easy, relatively simple way to incorporate it, and have it do the right thing. Even the article you cited tells me, "Go read a bunch more, and try a bunch of tools, and see what you can (eventually) achieve (or not)!"
from vc-data-model.
PR #1448 has been raised to address this issue. This issue will be closed once PR #1448 has been merged.
from vc-data-model.
PR #1448 has been merged, closing.
from vc-data-model.
The issue was discussed in a meeting on 2024-03-06
- no resolutions were taken
View the transcript
2.9. Unnecessary direction attribute? (issue vc-data-model#1424)
See github issue vc-data-model#1424.
Brent Zundel: 1424 unnecessary direction attribute.
Ivan Herman: there's a PR for that one.
… and it's been merged. So lets close it.
from vc-data-model.
Related Issues (20)
- What does the hash values in §B.2 mean? HOT 4
- Proposal: remove ambiguity and asymmetry as it relates to subject identifiers HOT 7
- Do we need sha3-512 in the vocabulary tables? HOT 6
- Should we use `Ed25519Signature2020` in the Examples? HOT 4
- Unmatched HTML Tag HOT 3
- Revisit Verifiable Credential media types HOT 20
- consider merging 3.4 and 5.1 as both sections are about the credential lifecycle. HOT 1
- Add issuee definition HOT 17
- Truth (or falsity) is not part of VCDM ecosystem HOT 4
- `credential repository` vs `repository`, and definitions in _1.2 Ecosystem Overview_ vs _2. Terminology_ HOT 6
- Consider explicitly allowing/recommending language maps for use in internationalisation. HOT 5
- Example of Use of renderMethod HOT 3
- Suggest to make explicit reference to the JADES standard HOT 8
- EnvelopedVerifiablePresentation missing in https://www.w3.org/ns/credentials/v2 HOT 3
- VC-JWT examples are out-of-date HOT 6
- Inconsistency between spec and schema HOT 2
- Unify cryptographic hash expression formats HOT 4
- Could not define "name" and "description" as attributes of my type HOT 10
- Comments/Suggestions on Privacy Considerations HOT 1
- SD-JWT fields in the v2 context should use `"@type": "@json"`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vc-data-model.