<g> + <x/> or <itag> all with appropriate attributes will be sufficient. Regarding bad XLIFF, did we ever produce simple examples and howto's? I have also seen some atrocious XLIFF implementations, but as long as they are valid XML and conform to the DTD/Schema we can cope.
Best Regards,
Andrzej Zydroń
CTO
XTM International
Tel: +44 (0) 1753 480 469
Fax: +44 (0) 1753 480 465
Mob: +44 (0) 7966 477 181
email: azydron@xtm-intl.com
www: http://www.xtm-intl.com
Skype: zydron
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you may not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.
On 27/10/2011 13:12, Yves Savourel wrote:
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 --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org