RE: [xliff-inline] Proposed requirement for inline SC: XMLwell-formed-ness as a design goal for XLIFF 2.0 inline markup

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

Hi Yves,

Thanks for letting me know the preferred operating procedure. I'll add my proposal to the requirements section.

And regarding your reply to my stated preference for identifying escaping XML markup as *not a best practice*:

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

Yves > . . . frankly 
> I don't know how we could represent '<' in 
> XML content as anything but some kind of 
> escaped sequence.

I am not objecting to the practice of preserving code. I am specifically objecting to the practice of escaping XML markup. Escaping XML markup (<bpt ctype="italic">&lt;i&gt;</bpt>yippy<ept>&lt;/i&gt;</ept>) is nothing but syntactic sugar. Or more exactly, syntactic saccharin (http://en.wikipedia.org/wiki/Syntactic_sugar#Syntactic_saccharin). Omitting the escaped XML (in this example) is no less clear (<bpt ctype="italic" />yippy<ept />, of course in both examples the required id would need to be included).

I think representing the reserved (or as it is referred to in the XML spec, "Predefined Entity") "less than" character in XML is adequately specified in the XML spec (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-predefined-ent). And more generally, I am not objecting to using <bpt> <ept> where it is needed. I'm objecting to its gratuitous use. Of course we need to enable a way to escape generic code (non-XML, i.e., RTF, C#, malformed XML, etc.), or non-balanced XML that spans segments, so that the XML processor does not garble it.

To summarize my position, best practice should be:

1. When representing well-formed, non-segment-spanning XML do it in an XML-friendly way
2. When escaping non-XML code, use <bpt> <ept> (or would it be <bx> <ex>?)
3. When representing mal-formed or segment-spanning inline XML markup, use <bpt> <ept>

---- snip here to skip the "soap box" portion ----
I get this way because I think the X in XLIFF is as important as the L and the I and the Fs. We use XML in the actual name of our standard not because the standard is written in XML (virtually all standards are these days). We use XML because XML is the mechanism we chose to solve the I (interchange) challenge. If we identify escaping the XML as a good practice, we're a bit hypocritical. 
---- now I step off my soap box ----

Sorry to be over the top. Just my humble opinion. And please forgive me if I also send my general summary to the XLIFF list as a reminder of our strategy (in general for XLIFF 2.0) to use XML process-ability as a design goal.

Thanks,

Bryan


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Monday, May 10, 2010 5:55 PM
To: xliff-inline@lists.oasis-open.org
Cc: arle@lisa.org
Subject: RE: [xliff-inline] Proposed requirement for inline SC: XML well-formed-ness as a design goal for XLIFF 2.0 inline markup

Hi Bryan,

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

Yes, please feel free to add the item to the requirement list. Since we have not gone through yet, I don't see any problem adding to it.
Please, add it to the wiki, in the same form as the others. Feel free to put a link to the thread of discussion for reference as well.


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

Add it to the list as well. But frankly I don't know how we could represent '<' in XML content as anything but some kind of escaped sequence.


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

Will do. It's nice of you to consider making XLIFF the priority on those days. We should try to work through email as needed too.

Cheers,
-ys





---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php