Proposed requirement for inline SC: XML well-formed-ness as adesign goal for XLIFF 2.0 inline markup

[<bryan.s.schnabel@tektronix.com>]

Hi Yves,

 

As you move from Step 1 (scope) to Step 2 (requirements). I'd like to propose a requirement. In general, it is that we carry our overall TC design goal for XLIFF 2.0, "use good XML modeling as a philosophy for design," into the inline SC work.

 

I'm sending this to the list because I'm not sure if you want us to add proposals directly to the wiki, or introduce them to this list. If your preference is for the former, I'll gladly go to the wiki. If it is for the latter, here are my thoughts:

 

Specifically, it's my old (probably tedious) argument that while there are real world cases where our old <bpt>, <ept> markup are required, our spec should specify that when possible, the best practice is to use something along the lines of our preferred <g> and <x>. And using markup that acts like <bpt>, <ept> should only be used for unbalanced inputs.

 

Here's a snip from an email I sent to Arle in response to the TMX group's request for feedback (with Arle's permission, I'd be happy to send you the whole thread. I think it nicely represents some good counterpoints):

---------------------------------------------------------------

 

I would like an inline element that acts like a well-formed XML element. I think this should be expressed as the recommended best practice and first choice. For example, to represent this string:
 
<p>I really <i>love </i>skiing.</p>
 
we should use a mechanism that is an inline, like this:
 
(1) <seg>I really <inline type="i">love </inline>skiing.</seg>
 
I would strongly wish to not (in most cases) see a mechanism like this:
 
(2) <seg>I really <in_start id="i_01" type="i" />love <in_end idref="i_01"  />skiing.</seg>
 
So I (begrudgingly) say we could offer the second mechanism, with the stipulation that it is a best practice to *only* use if in cases of inlines that span segments, perhaps like this:
 
<p>I really  love <i>skiing.
 
Snowboarding</i> is fun as well.</p>
 
<seg>I really  love <in_start id="i_01" type="i" />skiing.</seg>
 
<seg>Snowboarding<in_end id="i_01"  />is fun as well.</seg>
 
This may seem fairly obvious, but I remember being horrified when I saw a proposal for <itag> that only allowed the second mechanism (2), and discouraged the first (1).

 

---------------------------------------------------------------

Oh, and I'd really love it if we could discourage escaping XML code (like:

<seg> xxxxx<in_start id="i_01" >&lt;i&gt;</in_start>xxxxxx.</seg>

<seg>xxxxxx<in_end id="i_01" >&lt;/i&gt;</in_end>xxxxxx.</seg>

)

 

By the way, if you want me to attend a given SC meeting for discussion on this topic, please let me know ahead of time. My general goal will be to attend as many SC meeting as I can, but it means cancelling my early morning sunrise plans with my group.

Thanks,

 

Bryan