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

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Rodolfo, Arle, and Andrzej,

I would (as long as <g> is included) add my +1.

As the three of you have rightfully said, provided the appropriate set of attributes are available, I cannot think of anything I've been asked to process (XML, HTML (wellformed and not) firmware, RTF, instrument codes, crusty old Interleaf, etc.) that could not be happy with just the <g> and <x/>.

- Bryan
________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya [rmraya@maxprograms.com]
Sent: Tuesday, October 25, 2011 3:13 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] [xliff-inline] Representing information for the starting/ending/standalone parts

Hi all,

Arle reminded me what we found when we were working on inline tags for TMX 2.0. The truth is that we only need empty isolated tags for representing all inline markup but some developers want more.

As mentioned above, isolated tags are enough. Nevertheless, I understand the needs of those that want to enclose translatable text in an inline element.

As Andrzej said, there is nothing wrong with old  <x/> and <g>. We could use them for marking up any inline formatting. The key is in having the right set of attributes for those elements.

Going deeper, we only need an equivalent of <g> because the replacement of <x/> can be an empty <g>.

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel
Sent: Tuesday, October 25, 2011 5:12 PM
To: Andrzej Zydron
Cc: xliff@lists.oasis-open.org
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.

-Arle

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ń

CTO
XTM International
 <XTM_Cloud_logo_small.jpg>
Tel:         +44 (0) 1753 480 469
Fax:        +44 (0) 1753 480 465
Mob:       +44 (0) 7966 477 181
email:     azydron@xtm-intl.com<mailto:azydron@xtm-intl.com>
www:      http://www.xtm-intl.com<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<mailto:xliff-unsubscribe@lists.oasis-open.org>

For additional commands, e-mail: xliff-help@lists.oasis-open.org<mailto:xliff-help@lists.oasis-open.org>