Re: Summary of bidi discussion with Social Web WG

On 03/08/2016 23:59, Phillips, Addison wrote:
> I put a summary into the open issue in their github and I have to admit to being confused.
>
> One of the things I pointed out in my summary is that this conversation is not consistent with the items being discussed. The fields in question are 'processingLanguage' and 'textDirection' attributes in the ActivityStreams spec. Those attributes relate to *external* files, including text files, rather than to text contained in the actual annotation. My confusion is that there are actually votes to close the issue based on my summary... but the discussion you encountered had nothing to do with external resources/files.

My questions relate to discussions with the Social Web Working Group 
around https://github.com/w3c/activitystreams/issues/336 which relates 
to the Activity Streams spec, but there are also similar questions to be 
answered for Micropub and WebMention (also specs of the Social Web WG). 
The issue you refer to is a spin off reaction of Social Web folks 
against decisions taken for and by the Web Annotation WG related to the 
Web Annotation spec.

Please, let's focus on resolving the issue raised against the Social Web 
specs, linked to above, before reassessing the annotation issues, since 
the Social Web decisions are far more urgent, and those are what we'll 
be discussing later today.

(I also think that it doesn't help to conflate discussion about 
direction and language metadata, since they work in different ways and 
need different solutions, and that makes it difficult to get clarity in 
the argument.)

(During the meeting they will probably also want to discuss 
https://github.com/w3c/activitystreams/issues/338)

> I do agree that natural language text inside an annotation also needs language and base direction properties, of course. The problem that JSON doesn't provide content metadata for natural language strings (and thus document formats based on JSON have to define and provide this as [frequently quite ugly] additional attributes or extensions) is a real one. Many implementations have to deal with this or with the poor results that obtain when you don't have this information.


This discussion is about *text direction* not language.


> First strong is certainly better than no analysis for bidi. Statistical detection of language is better than no language information. But not building capabilities into document formats because algorithms like this "are better than nothing" is about like saying "there are ways to transcribe all scripts into the Latin script, so Unicode support is unnecessary". We don't really want a "separate direction property", but we do need direction (and language) metadata for natural language content in document formats (including JSON-based ones) lest we institutionalize a crappy experience.

The question is: *Is there any reason we need a direction property for 
the Activity Streams spec?*

Using heuristics (such as first-strong), and applying markup/controls to 
correct the cases where those heuristics are thrown, is being proposed 
as an adequate way of handling text direction in JSON.

(Note that we're NOT talking about a completely hierarchical HTML or 
other markup based document type, we're talking about objects and 
strings transporting data, although those strings may sometimes allow 
some markup internally.)

The Social Web group wants to know what value is accrued by having a 
direction property in addition to that. (Well, actually they don't want 
to know, they are asserting that there is none, and requiring us to 
prove that there is.)

Let's focus on that question, please.

ri

Received on Thursday, 4 August 2016 06:28:15 UTC