OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all,   See below one contribution to the simpleNote discussion that I forgot to forward.   Cheers, -yves     From: Felix Sasaki Sent: Tuesday, July 19, 2011 8:11 PM Subject: Re: [xliff] Element simpleNote   Hi Yves,   again, feel free to forward this.   My proposal to resolve this would be: use the definition of the ITS note at http://www.w3.org/TR/its/#locNote-definition this is independent of the actual usage, as an attribute / element / with or without XPath.  Say then that you implement the definition following ITS locally, but not ITS globally, for the reasons about XPath you mentioned below.   The value of the above would be that we have clear paths of conformance: an implementation of ITS in XLIFF conforms to the definition and the local implementation, but it potentially adds another, non XPath based option.   Best,   Felix 2011/7/19 Yves Savourel < ysavourel@enlaso.com > > a. Why can't we use existing standards such as W3C ITS in XLIFF? > If I remember correctly, we have "Reuse" as one of our XLIFF > 2.0 Mantras. If we go with ITS, for a "simple note" we can use the its:locNote attribute without anything else. It goes on the element you want to annotate. We could still control which elements allow it or not using the schema. If we were to match the current locations we would allow its:locNote on <segment>, <unit>, <source> and <target>. Two possible drawbacks: 1) An attribute value cannot have a rich content (formatting, multi paragraphs, etc.) But maybe that is not an issue with a *simple* note. 2) Since all the <source> (or <target>) elements have no common parent (they have a common grand-parent), we would not be able to assign a note to all source or all target at once by specifying it in <unit>. On ITS overall: I would think twice before using any XPath-based options. The main issue with this is that it pretty much forces the use of a DOM-based parser for XLIFF, which could be a problem with large documents. Cheers, -ys  

Is it really the intent to to implement specific XLIFF features using elements of another standard? It is appropriate to pick and choose one or two items from this standard, and a couple for another standard, and one from another standard to make up the XLIFF specification? It seems that it could become difficult to manage all of the interdependencies and if a referenced standard changed or removed a function, XLIFF could be forced to change just for this reason. David Corporate Globalization Tool Development EMail: waltersd@us.ibm.com Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721 CHKPII: http://w3-03.ibm.com/globalization/page/2011 TM file formats: http://w3-03.ibm.com/globalization/page/2083 TM markups: http://w3-03.ibm.com/globalization/page/2071 Yves Savourel ---07/21/2011 11:49:31 AM---Hi all, From: Yves Savourel <ysavourel@enlaso.com> To: <xliff@lists.oasis-open.org> Date: 07/21/2011 11:49 AM Subject: FW: [xliff] Element simpleNote Hi all, See below one contribution to the simpleNote discussion that I forgot to forward. Cheers, -yves From: Felix Sasaki Sent: Tuesday, July 19, 2011 8:11 PM Subject: Re: [xliff] Element simpleNote Hi Yves, again, feel free to forward this. My proposal to resolve this would be: use the definition of the ITS note at http://www.w3.org/TR/its/#locNote-definition this is independent of the actual usage, as an attribute / element / with or without XPath. Say then that you implement the definition following ITS locally, but not ITS globally, for the reasons about XPath you mentioned below. The value of the above would be that we have clear paths of conformance: an implementation of ITS in XLIFF conforms to the definition and the local implementation, but it potentially adds another, non XPath based option. Best, Felix 2011/7/19 Yves Savourel < ysavourel@enlaso.com > > a. Why can't we use existing standards such as W3C ITS in XLIFF? > If I remember correctly, we have "Reuse" as one of our XLIFF > 2.0 Mantras. If we go with ITS, for a "simple note" we can use the its:locNote attribute without anything else. It goes on the element you want to annotate. We could still control which elements allow it or not using the schema. If we were to match the current locations we would allow its:locNote on <segment>, <unit>, <source> and <target>. Two possible drawbacks: 1) An attribute value cannot have a rich content (formatting, multi paragraphs, etc.) But maybe that is not an issue with a *simple* note. 2) Since all the <source> (or <target>) elements have no common parent (they have a common grand-parent), we would not be able to assign a note to all source or all target at once by specifying it in <unit>. On ITS overall: I would think twice before using any XPath-based options. The main issue with this is that it pretty much forces the use of a DOM-based parser for XLIFF, which could be a problem with large documents. Cheers, -ys

Hi David, all, > Is it really the intent to implement specific XLIFF features > using elements of another standard? > It is appropriate to pick and choose one or two items from > this standard, and a couple for another standard, and one > from another standard to make up the XLIFF specification? > It seems that it could become difficult to manage all of > the interdependencies and if a referenced standard changed > or removed a function, XLIFF could be forced to change > just for this reason. For what it's worth, I think using directly other standards may be a good idea in some cases, and a bad one in others. For example, you can imagine that, if XLIFF would hold a list of terminological entries, it may be simpler to provide the place to include some TBX-type section, than to reinvent a whole set of elements for it. In some other cases, it may not be a good idea to use just one element/attribute to implement a feature that is deeply nested in an XLIFF structure. It has to be practical. Note that as far as reference to a standard, I would imagine that if any other vocabulary is used in XLIFF, it would be for a given version of that standard, and that wouldn't change until XLIFF itself needs to change. I would be more worry about having to manage namespaces: many tools may not do it properly. As for the simpleNote, and ITS in general, I think Felix's point is well put. ITS first defines data categories (i.e. features). And it offers one possible implementation of them using the ITS namespace. But the importance is to have the feature, not necessarily to implement it using the ITS namespace. As long as the one in XLIFF matches (or possibly extends) the one in ITS, ITS-driven tools can map it is using rules. In other words, an ITS-aware tool does not need to work on the ITS namespace to "understand" the feature. The semantic is more important than the syntax. Just thinking out loud. -yves