[TF-AIDN] notes from meeting on 10 August and updated documents for meeting this week

Meikal Mumin meikal.mumin at uni-koeln.de
Wed Aug 24 12:55:46 CEST 2016


Dear colleagues,

congratulations to the group which work on the draft for the Arabic
language table. But what happened to 06A8 and 0763, both of which occur in
the proposal for the root zone for Arabic language?

I also think that we should keep apart the rules and principles, which
guided how the language tables have been developed. Currently I can see
such discussions under the heading Variants, for example. I would opt for a
general document discussing the implementation of language tables to raise
awareness in the community about the underlying principles.

As for what concerns some case examples for African languages - both Hausa
and Wolof are without a doubt used by the communities today, and there is
some more material on the orthographies available in published form in
books and on the Internet. Maybe we could engage experts to produce
orthography statements. The other suggestion I had made was to coordinate
efforts from local communities, such as registrars, however would encompass
new outreach.

In this context I can already make reference to what I meant by lenience
when it comes to variant analysis - for example the Wikipedia article on
Arabic script use for Hausa
<https://en.wikipedia.org/wiki/Ajami_script#Hausa_Ajami_Script> already
states that "There is no standard system of using ajami, and different
writers may use letters with different values." Sometimes these are
communities of practice which live from the absence of standards. However,
once we get to variant rules, I will be able to consider if any of the
variant principles is in conflict with those usage patterns.

I have been thinking about principle 5 of 2.2.1:

Code point which represents a combination of letters in a language which
> has established contemporary use, where at least one of the constituent
> letters cannot be represented by a combination of letter code points and
> mark code points.


I think it was meant as failsafe pending the integration of new characters
by the Unicode consortium. We had cases where a unit of a given orthography
could be represented by a single code point, or a sequences of two code
points. Since we were aware that there are still composed graphemes lacking
integration into Unicode, we wanted to make sure that these could still be
integrated. Maybe the wording got skewed along the way and should be
adopted to something like:

Where a grapheme composed of two or more codepoints in the orthography of a
language in contemporary is not encoded as a single unit, but as a letter
code point and a mark code point, both codepoints must be integrated.

It's still skewed, but maybe you can suggest simplification.

Best wishes,

Meikal


On 23 August 2016 at 23:21, Sarmad Hussain <sarmad.hussain at icann.org> wrote:
>
> Dear All
>
>
>
> Here is a summary of the discussion from our previous call. Please feel
free to add any details, if these have been missed.
>
>
>
> The updated document and Arabic Language LGR are attached for our
discussion tomorrow.
>
>
>
> Second level LGRs
>
> =======================
>
>
>
> The changes in the Second level LGR Proposal for Arabic Script 0.3 were
discussed.  The changes were agreed.  It was noted that clause (v) deleted
in section 2.2.1 may need to be revisited.
>
>
>
> The group suggested that after the inclusion and exclusion principles for
the code points, the next step is to develop the principles for the
variants.
>
>
>
> Variants should be studied in three categories:
>
> i.                     Study variants within a language
>
> ii.                   Study variants across scripts – as it is important
for later integration
>
> iii.                  Study variants for international reachability
>
>
>
> We should start from the variant principles from the work done for Root
Zone LGR and the additional consideration, review and finalize these
principles.  The variant principles may be different from those for the
root.
>
>
>
> It was suggested data may not be available to do detailed analysis for
each language in the context of variants.  So some leniency should be
possible in those contexts to keep the analysis inclusive for some
languages.  It was shared that some concrete examples during the
discussions on variant principles may help address such challenges in data.
>
>
>
> Status of different language was shared.  Initial analysis for Urdu has
been completed.  For Arabic language, the WG has been working and completed
the language table, which will be circulated soon.  Initial version of
Pashto language table has also been done and will be shared with the task
force.  There is no progress for African languages due to lack of community
members from these languages.  It was suggested to arbitrarily pick up 1-2
languages and start with reaching out to relevant community to contribute.
There is interest in Persian and Sindhi language LGRs.
>
>
>
> Universal Acceptance
>
> ==================
>
>
>
> A set of cases was developed by UASG and shared – Use Cases for UA
Readiness.  It includes domain names and email addresses for mixing ASCII
and IDNs.  This document needs to be enhanced for Arabic script cases.
TF-AIDN should finalize the test cases for Arabic script and contribute to
the UASG document.  SaudiNIC has shared an initial list based on mixing RTL
and LTR labels, as a starting point.  TF-AIDN members should also test the
test-cases provided.
>
>
>
> It was agreed that a separate Working Group for UA.  Once the work is
done, it will be finalized by TF-AIDN and then communicated to UASG.  Those
interested in the work should share their intention with TF-AIDN list.  The
effort will be coordinated by Abdeslam.  TF-AIDN should also inform UASG
that it is working on the test cases and will provide the input.  TF-AIDN
UA WG will draft this statement to share for this purpose.
>
>
>
> Face to Face Meeting
>
> ==================
>
>
>
> We need to start working on an agenda for the meeting.
>
>
>
> Regards,
> Sarmad
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> TF-AIDN mailing list
> TF-AIDN at meswg.org
> http://lists.meswg.org/mailman/listinfo/tf-aidn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.meswg.org/pipermail/tf-aidn/attachments/20160824/181e6c0a/attachment.html>


More information about the TF-AIDN mailing list