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:
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
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.
Tel: +44 (0) 1753 480 469
This message contains confidential information and is
intended only for
Fax: +44 (0) 1753 480 465
Mob: +44 (0) 7966 477 181
the individual named. If you are not the named addressee you may
disseminate, distribute or copy this e-mail. Please notify the
immediately by e-mail if you have received this e-mail by
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
information could be intercepted, corrupted, lost, destroyed,
late or incomplete, or contain viruses. The sender therefore
accept liability for any errors or omissions in the contents of
message which arise as a result of e-mail transmission. If
is required please request a hard-copy version. Unless
otherwise this message is provided for informational purposes
should not be construed as a solicitation or offer.
On 08/10/2011 23:41, Schnabel, Bryan S wrote:
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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com