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

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Yves,

IMHO, the goal should be to reduce the number of inline elements to a reasonable minimum amount. That minimum doesn't have to be 1 or 2, it could be more if necessary. 

Element names don't matter at this moment; simplification is more important.

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

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf
> Of Yves Savourel
> Sent: Thursday, October 27, 2011 10:13 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] [xliff-inline] Representing information for the
> starting/ending/standalone parts
> 
> 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/str
> ings.html
> http://www.joulespersecond.com/2010/04/android-tip-proper-
> pluralization/
> 
> 
> cheers,
> -ys
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-help@lists.oasis-open.org