Re: [xliff-inline] Splitting non-clonable codes

[Andrew Pimlott <andrew@spartanconsultinginc.com>]

I'm not sure I understand--what does a tool do if it sees transformed="yes" and can't handle it?  Raise an error?  How is that an improvement?  If you see transformed="yes", does that even let you determine the original form unambiguously?  (Since the flag is binary, it only works if there are only two possible forms.)

My first thought is that this line of thinking is catering to poor implementations, and we just shouldn't do it.  If the standard specifies that two representations are equivalent, implementations should honor both.

But my second thought is that if we do want to make it easier for "limited" implementations, we should specify a "normal form" that uses the simplest markup.  Then, you could put a flag at the top of the file indicating whether it is in normal form.  If a tool accepts only normal form, it can reject non-normalized input and tell you to run it through a normalizer first.

Andrew

On Tue, Feb 14, 2012 at 8:29 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi Bryan, all,

> ... I've been thinking about the quandary expressed
> by Fredrik regarding the difficulty in knowing how
> to preserve the original span elements upon the
> conversion back to original format in cases where
> a split occurred.

Actually we discussed this. One idea that Fredrik suggested would be an optional transformed='yes|no' 'yes' meaning the current notation was modified, 'no' meaning the current notation is the original.

Cheers,
-yves


---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org