OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Modified: XLIFF TC Meeting

Submitter's message
added minutes
-- Dr. David Filip
Event Title: XLIFF TC Meeting

Date: Tuesday, 02 December 2014, 11:00am to 12:00pm EST

Please get the dial in information from our private Action Item here:

This meeting counts towards voter eligibility.


I Administration (0:00 - 0:10)
  A. Roll call
  B. Approved by CFD meeting minutes, 18 November 2014

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

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

IV Current and New Business (0:55 - )


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


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

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.

Owner: Bryan Schnabel
Group: OASIS XML Localisation Interchange File Format (XLIFF) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link

Microsoft Outlook users: You will see event notifications requiring further action in your Outlook mail application.
Non-Outlook users: We still recommend subscribing to a Group or organization-wide calendar to keep your calendar updated.

  • Learn more about subscribing here.
  • View the updated Group web calendar here.

Attachment: ical_38830.ics
Description: application/ics

PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
DESCRIPTION:Please get the dial in information from our private Action I
 tem here:\nhttps://www.oasis-open.org/apps/org/workgroup/xli
 ff/members/action_item.php?action_item_id=3663\n\nAgenda: I 
 Administration (0:00 - 0:10)\n  A. Roll call\n  B. Approved 
 by CFD meeting minutes\, 18 November 2014\n     https://list
 s.oasis-open.org/archives/xliff/201411/msg00078.html       \
 n\n(* indicates new since last meeting)\nII XLIFF 2.1 (0:10 
 - 0:45)\n  A. Versions and Modules - Yves\n     https://list
 s.oasis-open.org/archives/xliff/201410/msg00037.html\n  B. P
 rovenance and Change Track Module (Yves)\n     https://lists
 .oasis-open.org/archives/xliff/201410/msg00045.html\n  C. IT
 S: Preserve space and Language Information\n       https://l
 ists.oasis-open.org/archives/xliff/201410/msg00054.html\n  D
 . @disabled in Validation Module. Fix example. Add constrain
 t? (Bryan)\n       https://lists.oasis-open.org/archives/xli
 ff/201411/msg00000.html\n  E. TBX &ndash\; XLIFF Mapping - t
 his will be a note (DavidF)\n  F. ITS IG Call 2014-11-10 - Y
 ves\n     https://lists.oasis-open.org/archives/xliff/201411
 /msg00037.html\n  G. Do we have to have the schemas embedded
  in the specification? - Yves\n     https://lists.oasis-open
 .org/archives/xliff/201411/msg00040.html\n     - no ruling f
 rom OASIS as of 30 November\n  H. Terminology data category 
 - Yves\n     https://lists.oasis-open.org/archives/xliff/201
 411/msg00041.html\n  I. ITS IG ACTION-56: Do write up of pro
 cessing its+xliff files - Yves\n     https://lists.oasis-ope
 n.org/archives/xliff/201411/msg00047.html\n  J. Provenance D
 ata Category - Yves\n     https://lists.oasis-open.org/archi
 ves/xliff/201411/msg00052.html\n  K. *ITS module section(s) 
 in the specification (Yves)\n     https://lists.oasis-open.o
 rg/archives/xliff/201411/msg00083.html\n  L. *Template/Model
  for TBX Mapping with XLIFF v2.0 and Higher Version 1.0 (Dav
 idF)\n     https://lists.oasis-open.org/archives/xliff/20141
 1/msg00091.html\n  M. *A quick note on &quot\;Notes&quot\; (
 DavidF)\n     https://lists.oasis-open.org/archives/xliff/20
 1411/msg00092.html\n  N. *ITS Module URI (Yves)\n     https:
      \n\nIII Sub Committee Report (0:45 - 0:55)\n\nIV Curren
 t and New Business (0:55 - )\nGroup: OASIS XML Localisation 
 Interchange File Format (XLIFF) TC\nCreator: Bryan Schnabel

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]