[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: XLIFF TC Meeting
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)
(* indicates new since last meeting)
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.
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)
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?
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:
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?
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.
BEGIN:VCALENDAR CALSCALE:GREGORIAN METHOD:REQUEST VERSION:2.0 PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VTIMEZONE TZID:America/New_York BEGIN:STANDARD DTSTART:20001029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T060000Z TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20000402T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T070000Z TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT STATUS:CONFIRMED TRANSP:OPAQUE DTSTAMP:20141208T194028Z DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20141202T110000 DTEND;VALUE=DATE-TIME;TZID=America/New_York:20141202T120000 SEQUENCE:1 SUMMARY:XLIFF TC Meeting LAST-MODIFIED:20141208T194028Z ORGANIZER:firstname.lastname@example.org 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 "\;Notes"\; ( DavidF)\n https://lists.oasis-open.org/archives/xliff/20 1411/msg00092.html\n N. *ITS Module URI (Yves)\n https: //lists.oasis-open.org/archives/xliff/201411/msg00097.html\n \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 URL:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=38830 UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=38830 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR