[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: XLIFF TC Call
|
Event Title: XLIFF TC Call Date: Tuesday, 21 March 2017, 11:00am to 12:00pm EDT Description Please get the dial in information from our private Action Item here: This meeting counts towards voter eligibility. Agenda I. Approve meeting minutes for 7-March, 2017 https://lists.oasis-open.org/archives/xliff/201703/msg00159.html II. As specified earlier, let's focus on the end game plan. III. SOU readiness IV. Sub Committee Report (0:45 - 0:55) V. Current and New Business (0:55 - Minutes Attendance: Yves, Lucía, Bryan, Souroush, David F., Chase Tingley, Phil, Tom.
dF: Regrets from Felix. We have quorum. Phil will gain voting rights after this meeting. Chase has first attendance towards voting rights.
B: I move to approve the meeting minutes from last meeting. https://lists.oasis-open.org/archives/xliff/201702/msg00215.html
DavidF: I second. B: No objections. Meeting minutes approved.
Df We can close issue 38. Souroush made the changes and Felix has reviewed it. Do I have a second to approve this change? B: I second. dF: no dissent, motion carried
dF: for the localization note issues. This is not fully done, but Felix added rules covering many use cases. He is still adding the description/alert support, but I would like to technically close it. Yves, do you agree that it is a partial overlap category?
Y: I won’t disagree.
Df: is it fixed or won’t fix?
Y: I have not gone through the details, but the rules seem to be looking at the issues. dF: Ok is this resolved?, obviously still to be fully applied.. Do I have a second? B: I second dF: no dissent, motion carried
dF: the schema tree still needs to be updated, but this was approved last time..
dF: Let’s talk about the CTR related issues
Chase: I think there is a number of open issues. The question that I have been discussing offline is whether ctr is ready for the prime time, especially considering the pressure towards the XLIFF 2.1 release.. Y: I tend to agree with Chase. dF: my concern would be that people might be using the version 2.0 that is not right, the user base might be growing for the wrong solution.. Y: but it might be better to wait to have it in a version that works, than implementing something that has not been completely tested.
Df: Phil, Chase, are you using the ctr?
Chase: we do, but I do not remember exactly how as I didn’t develop the code..
dF: i know the MSFT object model has some implementation, but I do not know if it is been reused by anyone.
Ch: the counter argument would be that it is safer to have one imperfect than two imperfect versions.
Y: The implementation implements all of the cases except when you have inline codes in units. How do you represent things that have been deleted before? We are running into a lot of issues, not only the serialization. That is why we need to have a solid implementation before releasing it. That is my thought.
dF: if we do not kill the ctr, we are preventing extensions from doing the same thing. I am trying to see what the options are. We did not manage to create a new public review version for today because of the open issues, so we have at least until early April to see what is implementable or not. My fear is that if we do not do it now, it might have to wait for three or more years. Judging based on our speed with releasing 2.1
Ch: the timing is important. I do not know how much flexibility we have to fix this.
dF: the other parts are pretty stable, we could go without ctr. But killing the CTR update is also expensive in terms of editorial work.
Y: Why do you want to deprecate the CTR 2.0?
dF: if we have the old one in 2.1, CTR 2.0 is the law and implementers must respect it as a module. You might be happy with that. I was always skeptical about track changes in XLIFF. Doing change tracking as a module is extremely limiting, because you can have core only edits. If you really need tracking, you should do it orthogonally with a version control such as git.
Y: I agree with you, it is difficult to deal with track changes as a module. But depending on your workflow and other things, you might not be able to address all use cases orthogonally.
Df: I became CTR owner of necessity, as there was no one else to do it. I built on use cases I heard of from Chase and Phil. Comparing versions of target before and after an edit seems the chief use case and this is what the current solution does. I think it is a design exercise, what is achievable with a tracking *module*.
Ch: The features that are on the module are too broad. I think the ctr in 2.0 would work for some cases like changing the attributes, although I do not know if anybody using it.
Df: the item is working exactly as before, it could always track notes, it is no feature creep, the only change is actually a restriction on what you can track now. You can do target comparison quite easily. This is a good use case. If there was a commitment to see if we can have a working implementation in a reasonable timeframe. It is actually up to us, when we want 2.1 released, there is np mandated timeframe. I do not know how much work you need to preform the implementation experimentation. It might as well take the same time as removing CTR 2.1 from the spec.
Y: I doubt it, we should implement it also in real life. We really need experience with it. If somebody creates an extension that does the same thing, we could always welcome it later as a module.
dF: If you are implementing as an extension w/o deprecating CTR 2.0, you cannot treat it as an independent feature. You are allowed to add what there is not, similar as adding itsm:lang in the ITS module, it must respect that there already is srcLang and trgLang and xml:lang. So if we do not kill the module, you are not completely free to work on the feature as you please, you must respect the features that already are in the current module.
Y: It is not there if we are trying to build it.
dF: There is an overlap.
Y: maybe the extension could just work on the inline and then be added at some point.
Df: With my editor’s hat on, I would just kill the module and give you the freedom to work on the feature as you please. You don’t think it’s limiting to work along the 2.0 module?
Y: I do not see the problem.
ch: We have to work on an extension, and simply focus on the content model. We will have to take the existing ctr legacy. Not sure if I fully comprehend the module/extension issue.
dF: if you are working on an extension, you need to respect the module. There is a feature, you cannot redevelop from scratch if there is a current module.
Ph: we all agree that having an implementation would be perfect, but we do not how long and what it would involve. Do we need to make the decision now?
dF: Yes, we need to make a decision to be able to move forward with 2.1.
Ph: we cannot predict the impact right now. If the new implementation has incompatibilities with 2.0 that is sth that we can discuss at a later time.
Y: you can have the problem with any module.
dF: If you work on it between releases, you have to work with extensions respecting current modules.
Y: so you cannot progress.
df: you can, but in a modular way.
Ch: when the extension is a violation of the standard. It seems like the question is about timing. Is the act of developing the new one, is that a violation of the standard? can we synchronize these things so it is added as a module?
Y: my though is that Ocelot is the only one using that feature. I have not heard of anybody or read about anybody using it.
Y: killing a module, I do not see a problem, but you should not do it unless you have a good reason to do it.
dF: the reason is that is not working, and we are working on the new version. If we do not have it for 2.1, then what? I became the feature owner of necessity, but my primary responsibility is as the 2.1 editor, so we can progress with the 2.1 release. I cannot progress if we do not make a decision.
Y: why is that?
dF: the 2.1 is the 2.0 plus new things and clarifications and you cannot tell me if you need to violate the old module or not.
y: I cannot.
dF: so I say let’s kill it, so you can experiment as you please without any limitations.
Y: internally you can do it whatever you want.
dF: I understand. But if you find out in your experimentation that you need to violate the module, would you do it or respect the module?
Y: I would create an extension, and it could be added in the new version, deprecating the old one.
B: we have a problem that has been identified, but we do not see any instance that this shortcoming is causing issues, I am inclined to agree with Chase, this might be a problem or not. I would leave it as is. And we work on the background on introducing it in 2.2.
dF: so we would be forking.
Y: I do not follow where the fork comes from?
dF: so you all (Chase, Yves, Phil, now Bryan) propose to leave CTR as it was in 2.0.
Phil: yes.
Df: If everybody agrees, it is ok, I will prepare the csprd03 like this for next meeting. If you do not see the issue, bless you.
B: the fact that you have found some issues on CTR, it does not mean that we will not find issues on other modules. Size restrictions and resource data are examples I can think of. There might be shortcomings – but I would not want to remove them in order to be able to improve them.
dF: there were three years to work on the CTR 2.1, no one cared. CTR is implemented in two major OS libraries. There are engineers that use it and do not talk to us. We do not know the size of the problem.
Ph: I do not see how keeping CTR 2.0 should stop the experimentation.
dF: it makes the future issue bigger. dF: if you can come back with a solution in a month, we should wait. If you are planning to take years, that’s fine with me. We can go ahead with 2.1 now.
Ph: if we kill CTR 2.0 ctr, we might have a problem in Ocelot for example.
dF: you can use still use it as an extension. You are free to use it, it just wouldn’t count as a module.
Ph: deprecating something is a decision for a larger audience rather than just the TC.
dF: that would be postponing the approval process for the Silicon valley Symposium in November. Deprecating the module does not prevent you from using it as an extension. We could do it editorially in two ways: deleting it or keeping as an informative section and stating that the ctr 2.0 namespace no longer has the module protection. It will even keep the same prefix. Ch: will it be the same namespace?. Df: The extension would keep the 2.0 namepace. The new namespace after done would be probably 2.2. The only change is, it will be considered an extension namespace, not a module namespace. Ch: This sounds good to me, there might be some issues though I cannot consider now..
dF: We are on the top of the hour, I will formulate this as a call for dissent on the issue 32 CTR Usability https://issues.oasis-open.org/browse/XLIFF-32 the CFD would be until the end of the week.. Ch: sounds good.. B: 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 |
Attachment:
ical_45024.ics
Description: application/ics
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:20170321T175529Z DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20170321T110000 DTEND;VALUE=DATE-TIME;TZID=America/New_York:20170321T120000 SEQUENCE:2 SUMMARY:XLIFF TC Call LAST-MODIFIED:20170321T175529Z ORGANIZER:workgroup_mailer@lists.oasis-open.org ATTENDEE;CUTYPE=GROUP:MAILTO:xliff@lists.oasis-open.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. Approve meeting minutes for 7-March\, 2017\n\nhttps://lists .oasis-open.org/archives/xliff/201703/msg00159.html\n\nII. A s specified earlier\, let'\;s focus on the end game plan. \n\nIII. SOU readiness\nhttps://lists.oasis-open.org/archive s/xliff/201702/msg00215.html\n\nIV. Sub Committee Report (0: 45 - 0:55)\n\nV. Current and New Business (0:55 -\nGroup: O ASIS XML Localisation Interchange File Format (XLIFF) TC\nCr eator: Bryan Schnabel URL:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=45024 UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=45024 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]