I am fully aware that a lot of work has gone into this, and that I have not been participating in the discussions. I had a long chat about the XLIFF inline proposals with Bryan in Wiesbaden and he encouraged me to post my views to the list to add to the thread. I fully respect the amount of work that has gone into this so far, but in my view it is falling again into the unnecessary complexity trap.
My premise is that there are only two types of inline elements: those with content and those without. I treat inlines that span text units as being without content as this is in our experience very rare and does not warrant special treatment.
This basically comes down to simplifying inlines down to the very wise format from OpenTag and XLIFF 1.0 through to 1.2: <g> + <x> nothing more is required.
The argument for <g> is that it maps very well for XSLT transformations and merge operations with XML content and increasingly most formats are now in XML and if they are not the logical thing is to put them into XML for localization processing and reverting to the native format after merging.
IMHO there was nothing very wrong with XLIFF 1.2 - a simplified form of XLIFF 1.2 is being proposed by the Interoperability Now group and we fully support this initiative as a sane and effective way of sharing XLIFF files across participating systems.
Best Regards,
Andrzej Zydroń
CTO
XTM International
Tel: +44 (0) 1753 480 469
Fax: +44 (0) 1753 480 465
Mob: +44 (0) 7966 477 181
email: azydron@xtm-intl.com
www: http://www.xtm-intl.com
Skype: zydron
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you may not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.
On 08/10/2011 23:41, Schnabel, Bryan S wrote:
Hi Yves, I really understand what you're saying. I just have three short comments: 1)(1) <sc>/<ec> alone or (2) both <sc>/<ec> and <pc>? . . . or (I thought I heard) (3) <pc> alone with attributes to also carry the load of <sc>/<ec>There is no option (3). We cannot represent spans segmented at the middle with <pc>...</pc> no matter what attributes it would carries.Exactly! I think we've gone the long way around to make my point. <pc> can be made to work across spanned segments with proper attributes (example will follow). But using <pc> across segments is as (in my opinion) ill-suited as using <sc>/<ec> in a single segment. I could do this: <p>These skis are good in <slang> Crud. Powder and packed powder</slang> would be better served by another ski.</p> = <seg>These skis are good in <pc fuct='start' id='s1' /> Crud.</seg> <seg>Powder and packed powder<pc fuct='end' idref='s1' /> would be better served by another ski</seg> Okay, so I've gone out of my way to com up with a silly example, but I only --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org