[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] [xliff-inline] Representing information for the starting/ending/standalone parts
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]