< Return to Calendar

* XLIFF TC Meeting (Conference Call)
Name * XLIFF TC Meeting (Conference Call)
Time Tuesday, 02 December 2014, 11:00am to 12:00pm EST
(Tuesday, 02 December 2014, 04:00pm to 05:00pm UTC)
Description

Please get the dial in information from our private Action Item here:
https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3663

Minutes

I Administration (0:00 - 0:10)

  A. Roll call: Bryan, Yves, David W., David F., Fredrik, Joachim, Lucia, Peter Reynolds, Michael Ow, Soroush, Tom, Uwe.

Regrets: Asanka, Felix

 

DF: will we have quorum on the next meeting?

Bryan: Apparently yes.

Df: I will a Doodle poll to see about quorum for next meeting dates.


  B. Approved by CFD meeting minutes, 18 November 2014
     https://lists.oasis-open.org/archives/xliff/201411/msg00078.html      

 

DF: we should have the provisional media type registration during the next few weeks, Robin will forward the agreed registration data to IANA within this week. Once we have the provisional registration we can merge the registration template with the 2.1 spec. The plan seems to be working so far.

B: Good news, thank you David.

(* indicates new since last meeting)
II XLIFF 2.1 (0:10 - 0:45)
  A. Versions and Modules - Yves
     https://lists.oasis-open.org/archives/xliff/201410/msg00037.html

F: this is the most important topic to discuss.

DF: some of the ITS features rely on modules, so it is also relevant to this topic. E.g. the Provenance category overlaps with the change tracking module. The update of the modules should be discussed. Fredrik, can you tell us the technical possibilities that are available?

F: from the technically side, there is no mechanism to prevent sby to put 2.1 modules into a 2.0 document. Putting a newer version of the module into an older version of the core should not be a problem. But what confuses me, is the case when we can have multiple versions of the same module on the same document. I do not know if we can block it, but we can have some language saying that we do not allow it. Might seem easy with just two versions, which would be the case now, but after some years we might end up with many different versions and with the need to update module info on different places.

DF: I am afraid that we cannot make a summary solution for that. Each new version of a module can specify how the old should be supported or not. We should try to avoid deprecation.

F: If the namespace remains the same, any change you make can be ignored by any processor that works with an older version. But if you need to add an attribute that needs maintenance during the roundtrip, then you might have a problem. The question is whether we allow multiple versions of the same module within the same document.

J: I agree that we should not allow it. Small updates should be published as additions to modules w/o actually affecting the previous version module functionality.

DF: I think that is a good idea to keep the functionality if there is not anything wrong with the old functionality. But e.g. change tracking does not support inline elements at the moment. And the new version of ctr could do it.

J: without that functionality it does not make much sense.

DF: Since this would basically invalidate the data of the old module, this is a clear case for deprecation.

DF: In case of ITS storage restriction, we have the case when you have a new profile for an existing module..

F: Yes, there is no need to have a schema or namespace change. I would add the new profile in the ITS module.

DF: so, the ITS module would define the profile using slr module’s extensibility. The profile should be added to the ITS module w/o affecting slr itself.

F: yes, that is the idea.

DF: will you propose the profile on the mailing list?

F: yes.

DF: ok, I will add it into the spec, as soon as available and vetted.

F: the problem with codepage, when you translate sometimes (often) you have different codepages on source and target.

DF: Similarly, ITS can restrict allowed characters, it is to better support legacy systems. In those cases it is better to express the limitations, rather than to ignore them.

DF: We will need to elaborate details.

F: It is best when you make additional features to the modules not part of those modules.

DF: we can have a generic conformance statement saying that we do not allow two versions of the same module ever.

DF: we need to add the MT confidence data to the mtc module. We can use a mapping plus mtc’s own extensibility instead of using the module itself. The ITS adds additional metadata.

Yves: the annotator is whoever did the ITS annotation.

F: what should watch out for cases that need to be allowed on the original module.

DF: I will try and create a strawman within the next couple of weeks to see if we need a normative text outside of the ITS module. I tend to think it should be fine with text in the ITS module only.

Y: I do not think you need to add anything to matches, you can use the ITS module only.

DF: writing the Constraints on the ITS module might be enough.

DF: the question is if there is a value in mandating the tools annotation on the matches module.

F: then it should be backward compatible.

DF:  I think that there is still one important question opened, it regards the handling of inline language information and inline whitespace handling. We have three options:

  1. To not allow this info inline
  2. A new module handling it.
  3. Having it as part of the ITS module.

B: I would vote for option 3.

DF: I think that none of the three solutions would we ideal. Having a new module for it makes also sense. What do you think?

B: I agree that it would be technically more efficient to have it as a new module. But that will not come into in existence until 2.2 as we already passed the deadline to have new modules.

DF: It think that this module could be easily defended as part of the approved ITS support feature, even if it went into a separate module.

Y: that brings us to another question: are you going to have to implement all the data categories? Do you need to implement the 19 categories?

DF: I do not see the need to implement all of them. You can do some of them. It would be even against the spirit of ITS to say you need to do all of them. They are indeed distinct categories to allow for modularity.

Y: if that is the case, we would need a normative text saying so on the ITS module.

F: I still prefer it to be as a separate module, even though it would work to have it as part of the ITS module.

DF: Before I work on this, I would like to have your ideas on this. What would be the name of the new module? For example, the core extension 1? Or xml: handling inline?

F: I do not have a name.

B: I prefer option B.

DF: what do others think?

Y: it will depend on how you want to represent this info with markup.

DF: If different ITS has the same scope, it can be gathered on the same markup.

Y: so we are basically defining an attribute that can go in any annotation. Then it is valuable to have a namespace, because you are defining an attribute. Personally, I would like have it in the ITS namespace.

DF: We do not have a strong solution, I will continue with that mark up in the ITS module and we can break it out later on if we feel so.

F: let’s move on, and see if we can have a clear proposal.

 

III Sub Committee Report (0:45 - 0:55)

DF: The only ISO update is that this is now with Chet, following our ballot, not yet with the OASIS leadership. I do not expect progress soon on the ISO front. We will inform you when we will now. The only point of today’s SC meeting is to renew the mandate as the current mandate expires by the end of 2014. The next symposium will be in Berlin in the first week of June 2015, again collocated with LocWorld as part of FEISGILTT.

 

B: Any new business?

Meeting adjourned.



Agenda

I Administration (0:00 - 0:10)
  A. Roll call
  B. Approved by CFD meeting minutes, 18 November 2014
     https://lists.oasis-open.org/archives/xliff/201411/msg00078.html       

(* indicates new since last meeting)
II XLIFF 2.1 (0:10 - 0:45)
  A. Versions and Modules - Yves
     https://lists.oasis-open.org/archives/xliff/201410/msg00037.html
  B. Provenance and Change Track Module (Yves)
     https://lists.oasis-open.org/archives/xliff/201410/msg00045.html
  C. ITS: Preserve space and Language Information
       https://lists.oasis-open.org/archives/xliff/201410/msg00054.html
  D. @disabled in Validation Module. Fix example. Add constraint? (Bryan)
       https://lists.oasis-open.org/archives/xliff/201411/msg00000.html
  E. TBX – XLIFF Mapping - this will be a note (DavidF)
  F. ITS IG Call 2014-11-10 - Yves
     https://lists.oasis-open.org/archives/xliff/201411/msg00037.html
  G. Do we have to have the schemas embedded in the specification? - Yves
     https://lists.oasis-open.org/archives/xliff/201411/msg00040.html
     - no ruling from OASIS as of 30 November
  H. Terminology data category - Yves
     https://lists.oasis-open.org/archives/xliff/201411/msg00041.html
  I. ITS IG ACTION-56: Do write up of processing its+xliff files - Yves
     https://lists.oasis-open.org/archives/xliff/201411/msg00047.html
  J. Provenance Data Category - Yves
     https://lists.oasis-open.org/archives/xliff/201411/msg00052.html
  K. *ITS module section(s) in the specification (Yves)
     https://lists.oasis-open.org/archives/xliff/201411/msg00083.html
  L. *Template/Model for TBX Mapping with XLIFF v2.0 and Higher Version 1.0 (DavidF)
     https://lists.oasis-open.org/archives/xliff/201411/msg00091.html
  M. *A quick note on "Notes" (DavidF)
     https://lists.oasis-open.org/archives/xliff/201411/msg00092.html
  N. *ITS Module URI (Yves)
     https://lists.oasis-open.org/archives/xliff/201411/msg00097.html
     

III Sub Committee Report (0:45 - 0:55)

IV Current and New Business (0:55 - )



Submitter Bryan Schnabel
GroupOASIS XML Localisation Interchange File Format (XLIFF) TC
Access This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
  • OASIS Open (General Membership)
  • General Public