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

[Yves Savourel <ysavourel@enlaso.com>]

Hi everyone,

I agree with Fredrick. Using only the 1.2 <g> and <x/> cannot handle all the cases. Even adding <bx/> and <ex/> doesn't handle everything (e.g. no way to distinguish a beginning/ending isolated from a beginning/ending simply not well-formed).

I think we all know and agree that a single <itag>-like element could potentially be used to represent all use cases of inline codes. I still recall David Pooley toying with that idea at TMX OSCAR meeting in snowy Salt-Lake-City in February 1998.

Such animal would be something like the 2.0 <ph> with several more attributes.

But I don't think using one element to represent everything makes necessarily things *simpler*: You still have to specify the same information. You are just moving the information from element names to attributes.

For example: <ph id="1" start="yes"/> and <sc id='1'/> represent the same thing, the syntax is different but the information carried is the same.

I would argue that having many attributes instead of a few elements with a few attributes makes thing simpler in some situations, but more complicated in others. Here are some examples of the drawbacks:

- I'm no XSD expert but I'm guessing it is harder to validate many cases on a single element than doing it when the cases are represented by a few elements.

- Doing simple operations like searching for a given type of code in a text editor is more complicated when you have to look for a combination of attributes rather than an element name. Same thing when you use XPath.

- Representing different functionalities with different elements usually makes things easier for people than having all options represented by a single element.

- Knowing what type of code you deal with would require more calls: you have to look at the element name, as well as at least one attribute, rather than just access the element name.

- etc.

Those are small intangibles that are difficult express or evaluate as they are not always rational. But none of them indicate any simplification.

I think we can greatly simplify 2.0 by using fewer elements than the nine used for codes in 1.2, but a) we may want to avoid going all the way in the other direction and use too few, and b) using a sub-set of the existing 1.2 is not possible.

All this said. It's still useful to see that there is some interest for a <g>/<pc>-kind element and the keeping of our requirement #17.

SC folks: I'll try to create that 1.2 -> 2.0 mapping table ASAP. That may help us in seeing how far we think we can "simplify" things without missing features.


Another thing: Andrzej, I'm afraid you are too optimistic when you say that people know and understand <g> and <x/>. I think the beloved <g> especially is used incorrectly quite a lot (instead of <ph>):

http://code.google.com/p/apps-for-android/source/browse/trunk/DivideAndConquer/res/values/strings.xml?r=134
http://nowdeveloping.blogspot.com/2010/02/previously-on-my-last-blog.html

Actually there are quite a few files labeled with the XLIFF namespace that are not very XLIF-like out there:

http://developer.android.com/resources/samples/ApiDemos/res/values/strings.html
http://www.joulespersecond.com/2010/04/android-tip-proper-pluralization/


cheers,
-ys