Next in thread → Next in month →

Re: [xliff] XLIFF 2.0 - dF Sanity Check of the spec - question for the editors #002

From
Dr. David Filip <>
Date
2012-10-25T15:43:06+00:00
ID
Thread
Re: [xliff] XLIFF 2.0 - dF Sanity Check of the spec - question for the editors #002
Thanks Rodolfo, unless someone comes with a counter example showing
that this is potentially harmful I propose to change this general PR
to MUST.

Thanks
dF

Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: 


On Thu, Oct 25, 2012 at 4:28 PM, Rodolfo M. Raya <> wrote:
>
> Setting xml:space="preserve" would not cause any damage when target language
> is Chinese, Thai or similar. It may just be meaningless.
>
> Changing from SHOULD to MUST is OK for me. It would help in checking
> compliance.
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya
> Maxprograms http://www.maxprograms.com
>
>
>
> -------- Original Message --------
> Subject: Re: [xliff] XLIFF 2.0 - dF Sanity Check of the spec - question
> for the editors #002
> From: "Dr. David Filip" <>
> Date: Thu, October 25, 2012 1:15 pm
> To: "Rodolfo M. Raya" <>
> Cc: 
>
> Thanks Rodolfo, sounds relevant, but would we break anything in these
> languages if we enforced xml:space preserve?
>
> Anyway, as I see it we cannot use this PR for validation purposes if
> it is not strict. I think that the import of this PR is that tools
> must be able to check source for xml:space behavior and be eventually
> able (based on some set of rules?) to replicate it in the target or
> not.
>
> Could we have a more granular specific requirement that would direct
> the space preserve behavior between siblings? For instance based on
> payload script.
>
> I see that this can get hairy and we probably do not want to go into
> details here.
>
> So the simplest thing would be to say MUST unless we find a case where
> this enforcement would break things.
>
> Finally, in case it turns out that neither of the above is possible,
> is the space preservation a general principle worth mentioning or just
> a best practice thing?
>
> Thanks
> dF
>
> Dr. David Filip
> =======================
> LRC | CNGL | LT-Web | CSIS
> University of Limerick, Ireland
> telephone: +353-6120-2781
> cellphone: +353-86-0222-158
> facsimile: +353-6120-2734
> mailto: 
>
>
> On Thu, Oct 25, 2012 at 2:20 PM, Rodolfo M. Raya <>
> wrote:
>> Spaces may be meaningless for the target language (Chinese, Thai, etc.)
>> Preserving spaces may not be necessary in all cases.
>> Regards,
>> Rodolfo
>> --
>> Rodolfo M. Raya
>> Maxprograms http://www.maxprograms.com
>>
>>
>>
>> -------- Original Message --------
>> Subject: [xliff] XLIFF 2.0 - dF Sanity Check of the spec - question for
>> the editors #002
>> From: "Dr. David Filip" <>
>> Date: Thu, October 25, 2012 11:06 am
>> To: 
>>
>> Dear Rodolfo, Yves,
>>
>> In Section 2.1, the second general processing requirement says
>>
>> When a <target> child is added to a <segment> element, the value of
>> its xml:space attribute
>> should be set to preserve if the xml:space attribute of the sibling
>> <source> element is set to
>> preserve.
>>
>>
>> Can we list a single possibly valid reason not to preserve if the
>> source is set to preserve?
>> If not, we probably want to say MUST instead of SHOULD.
>>
>> Thanks for your attention
>> dF
>>
>> Dr. David Filip
>> =======================
>> LRC | CNGL | LT-Web | CSIS
>> University of Limerick, Ireland
>> telephone: +353-6120-2781
>> cellphone: +353-86-0222-158
>> facsimile: +353-6120-2734
>> mailto: 
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> For additional commands, e-mail: 
>>
>> --------------------------------------------------------------------- To
>> unsubscribe, e-mail:  For additional
>> commands, e-mail: 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail:  For additional
> commands, e-mail: 
Next in thread → Next in month →