Dear all,

Thank you for many comments in Vancouver meeting.
I tried to summarize it as following;

1.
The purpose of mappings document is to define additional mappings in order to 
increase 
the probability of getting matching-results from the comparison between 
strings, 
which are not defined as protocols in the framework.

2.
The mappings document defines three types mapping.
There were no comments on the delimiter mapping and the special mappings.
So, we think that the discussion for them as additional mapping is closed.

3.
It was pointed out in the previous meeting that in local case mapping, 
there are some possibilities in which a local-case-mapped string 
does not match the expected string from the users. And then for this reason, 
it is necessary to confirm whether this mismatch is allowed.

So, Is my understanding of this correct?

ß(eszett) in German, ς(final sigma) in Greek and ı(dot less i) in Turkish 
are widely known as targets of language dependent mappings.
The current local case mapping can work for ı(dot less i) that map 
I(large I) to ı(dot less i) using language and context mapping.

When ß(eszett) and ς(final sigma) are case mapped after local case mapping, 
the results are not expected by the users.
In order to prevent it, it may be necessary not to perform the case mapping 
for characters that are handled by the local case mapping. However, this would 
mean a significant change to the framework document and we need to discuss 
whether this change is necessary.

In the current mappings document, the local case mapping can be selected 
only when case mapping is selected. 
We could modify the document so that in handling local case mapping's target 
characters 
 <according to the condition Casefolding(Specialcasing(cp)) != 
Casefolding(cp)>, 
the mappings in the Specialcasing.txt will be performed. For other characters, 
full case mapping in the Local case mapping will be performed instead.
And the profile that selects local case mapping does not select full case 
mapping in framework.

I would like to hear your comment about this.


Regard,
Nemo

--
Takahiro Nemoto
[email protected]




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis

Reply via email to