Dear all, Peter-san, Alexey-san, thank you for your quick response.
If you have any comments for open issues in mappings-06, I would like to hear
about it.
These comments will be reflected on the updated mappings document as -07 before
cut off date(2/14),
as it will influence the framework document.
There are two points that have not reached a consensus in the mappings document
.
(1) Define local case mapping as an alternative to case mapping in the PRECIS
framework
pros: German eszett, Turkish dotless i, etc. will not be mapped
contrary to the users' expectation.
cons: It is necessary to modify the framework document.
options:
(A) Support the change of -06
(B) Don't support the change of -06, and restore the algorithm
of -05
(2) Way to deal with the context dependent mapping for both Greek sigma and
final sigma.
(a) Define extra mapping table for sigma and final sigma inside mappings
document
pros: Sigma and final sigma will not be mapped contrary to users'
expectation.
cons: It will be necessary to update this document to follow unicode's
updated version.
(b) Leave it to unicode's definition
pros: It is not necessary to define extra mapping table for sigma and
final sigma.
cons: Unless unicode is updated and a new definition to map both sigma
and final sigma has been added,
final sigma will be mapped to sigma.
options:
(A) Support the above (a)
(B) Support the above (b)
I would appreciate your comment.
Regards,
Nemo
On 2014/02/05, at 19:41, Alexey Melnikov <[email protected]> wrote:
> On 05/02/2014 00:03, Peter Saint-Andre wrote:
>> On 2/4/14, 3:01 PM, Alexey Melnikov wrote:
>>> Hi Peter,
>>>
>>> On 24/01/2014 13:57, Peter Saint-Andre wrote:
>>>> On 01/24/2014 06:02 AM, Takahiro Nemoto wrote:
>>> [...]
>>>>> We changed the definition of local case mapping and
>>>> That is better, thanks. If I understand your text correctly, we might
>>>> want to say very clearly that a PRECIS profile needs to either use
>>>> case mapping or use local case mapping, but that it can't use both
>>>> (i.e., local case mapping is an alternative to case mapping, not
>>>> something additional on top of case mapping, since the local case
>>>> mapping rule will apply normal case mapping if there is no
>>>> locale-specific mapping).
>>> If that is the way we want to go, then this contradicts section 5 of
>>> draft-ietf-precis-framework:
>>>
>>> 2. Optionally, additional mappings such as those as specified in
>>> [I-D.ietf-precis-mappings]:
>>> 1. Delimiter mapping
>>> 2. Special mapping
>>> 3. Local case mapping
>>> 3. Non-local case mapping
>>>
>>>
>>> I.e. draft-ietf-precis-framework needs to be updated to make this clear
>>> as well.
>>
>> Agreed. I think that the definition of "local case mapping" has changed in
>> the latest version of the mappings document, such that (if we think the new
>> direction is appropriate) we'd need to do this:
>>
>> OLD
>> 2. Optionally, additional mappings such as those as specified in
>> [I-D.ietf-precis-mappings]:
>> 1. Delimiter mapping
>> 2. Special mapping
>> 3. Local case mapping
>> 3. Non-local case mapping
>>
>> NEW
>> 2. Optionally, additional mappings such as those as specified in
>> [I-D.ietf-precis-mappings]:
>> 1. Delimiter mapping
>> 2. Special mapping
>> 3. Either "local case mapping" from [I-D.ietf-precis-mappings] or
>> case mapping as described under Section 4.1.3 of this document
>>
>> Does that look right?
> Yes, this looks good. I think [I-D.ietf-precis-mappings] is definitely
> normative now with your new text (it wasn't before).
>
> _______________________________________________
> precis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/precis
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
