OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xliff] [xliff-inline] Representing information for the starting/ending/standalone parts

Hi all,

I'm not going to try to argue one position or another on this issue, but I'd add a note that supports Andrzej's general point. When we were working on trying to rationalize metamarkup elements in TMX, we initially took the viewpoint that vendors had been using the metamarkup tags in the â??wrongâ?? fashion (by avoiding <bpt> and <ept> in favor of the simpler elements) and that we needed to be much more aggressive in conformance in this area. It was then pointed out (by Yves, if I remember correctly) that the problem wasn't that the tools developers were trying to circumvent the standard, but rather that in many cases the filters they worked with simply did not analyze the markup to determine whether it was a open tag, a close tag, an isolated tag, etc. The standard was asking them for information that they didn't need and couldn't provide. 

As a result they tended to treat all markup as isolated. In essence, for the tools to function, they did not need the complexity of the TMX 1.4b metamarkup scheme and were better served by a â??dumberâ?? system. I know some tools can use (or even require) more detailed information, but maybe this observation and Andrzejâ??s note suggests that the additional information be addressed by optional attributes that qualify the tags for tools that can use the data, but which doesn't impose a burden for processing that tools may not want/need.

I don't have a stake in the actual format for this issue, but I'd also not want to over-engineer things in ways that cause problem because we want the (philosophically) â??rightâ?? markup.


On Oct 24, 2011, at 10:07 , Andrzej Zydron wrote:

Hi Everyone,

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Å?


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) <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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]