OASIS Open

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

dF: Attendance: Asanka, Bryan, David F. David Walters, Fredrik, Helena, Uwe, Tom, Lucia, Joachim, Yves

11 out of 15 voters present, meeting has quorum

B: Last meeting minutes were already approved. 18 February 2014 https://lists.oasis-open.org/archives/xliff/201402/msg00033.html

B: Reminder: Open call for volunteers to take minutes.

B: Public Review III is complete https://lists.oasis-open.org/archives/xliff/201402/msg00015.html. We got over 40 comments but I don’t think any of them were substantial.  If we conclude that, we will be on track to approve the Committee Specification.

David has started the media registration template.

Do you plan to go through all the changes, in my opinion only 234 has potential to be substantive; the rest I think can be editorial and can be approved as such summarily unless anyone objects.

B: Is there P&L SC after the TC?

D: I have sent the invite for the P&L SC meeting, the topic is CFP for XLIFF Symposium

http://www.localizationworld.com/lwdub2014/feisgiltt/

D: On the media type registration: Paul created a doc template for us, and I will just take it and make it a DocBook article, so that it can be later on easily merged with the 2.1 spec. Rememember the current template we approved is for provisional registration and we want to flip the provisional flag once 2.0 becomes OASIS standard.

B: The only comment that can imply substantial changes is 234. (https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker).

D: my counterproposal is to add <xliff> to the listing of elements that prohibit xml:lang. This would be just fixing this clear omission, whereas the other proposal has more impact on the spec.

B: I don’t think that either of the proposals would have any negative impact.

Y: there is already processing requirement that says that the language of source and language should be the same as the languages defined at the beginning of the file. We did not have time to think about it. The problem is that we did not test it.

Y: I do not think that it is a major change at all, if we implicit or explicit restraint the language of source and target to the languages defined earlier, then the inheritance is being taken care of.

D: If allow the attribute on the inheritance path, we might give the impressions to the people that they can actually set the language this way, when actually cannot. I think it is more transparent if we do not allow them to do it upfront. The xml namespave attribute simply does not make sense in XLIFF structural elements because it conflicts with its source and target language attributes.

Y: I disagree.

D: what’s the point of allowing it, it can only create confusion?

Y: Not at all. You just make sure that the language is the same as the implicit value, that’s it.

F: Forbidding it everywhere would makes it easier to process.

Y: But what if you want to add a note in a different language. I do not agree with the principle of forbidding things when we do not need to.

D: I do not think it is a big issue. I just think that it would be easier to fix if we follow what I explained before. I think it is better if we vote. Remember we introduced this to prevent clash of xml namespace attributes used in xliff core with potential extension. There is too much potential for undefined behavior if we don’t prevent use of xml:lang on the inheritance path. The side use case of notes in different language can be addressed by both solutions. And forbidding the attribute makes the main success scenario simpler.

B:  Two choices:

1.    [proposed by dF] Prohibit xml:lang in <xliff> in addition to the other places where it is now forbidden.

2.    [proposed by Yves] Remove the provision of section 4.3.2 "xml:lang MUST NOT be set on either the <file>, <group> , or <unit> element."2) Remove the warning text in that same section "4.3.2.1 xml:lang". 2) Change the constraint in section "4.2.2.12 source" from:When a <source> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element. To:[[When a <source> element is a child of <segment> or <ignorable> the explicit or inherited value of the OPTIONAL xml:lang attribute MUST be equal to the value of the srcLang attribute of the enclosing <xliff> element.]] 3) Change the constraint in section "4.2.2.13 target" from:When a <target> element is a child of <segment> or <ignorable> and the OPTIONAL xml:lang attribute is present, its value MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element. To: When a <target> element is a child of <segment> or <ignorable> the explicit or inherited value of the OPTIONAL xml:lang attribute MUST be equal to the value of the trgLang attribute of the enclosing <xliff> element.

Votes:

1. DF, Bryan,

2. Tom, Yves, D. Walters,

Abstain: Helena, Fredrik, Lucia, Joachim, Asanka, Uwe.

DF: Option 2 carries with three votes.

B: This solution has been also categorized as editorial. We need to decide as TC if it is a substantive or editorial change. Is there any argument against this change being categorized as editorial?

DF: I will abstain if we vote on it. I won’t block consensus.

B: I agree with Yves, I think it is an editorial change.

DF: I think stakeholders can complain about this in later stages.

Y: The effect is basically the same, so it does not contradict any previous decision.

B: Following OASIS regulations, the only stakeholders who could complain about this change not being editorial, would be the members of the TC themselves.

dF: That is true for the CS step, but in later stages it will open to all OASIS members.

B: Ballot: I propose that the resolution that we have just agree on, results in an editorial change to the csprd03 spec (“yes” means editorial, “no” means substantive, abstain)

Y: I second.

Votes:

Yes: Fredrik, Yves, Bryan, Uwe, DavidW.

No:

Abstain: Helena, Tom, DavidF, Lucia, Joachim, Asanka.

DF: The motion carries with five “yes” votes.

B: I am going to assume that people had read these issues on the tracker.

B: I call for dissent that comments 227-240 are editorial.

DF: I second.

B: No dissent, so all comments and potentially resulting changes are declared as editorial. Next meeting, we will hopefully be in a position to summarize the changes made since last review and move forward. We should look at the tasks we have assigned and complete them.

We should also have to have a look at SOU. https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker. We should have as a TC a target to have all the features of core implemented and modules if possible, this is to demonstrate implementability of all core features. If you own a module and feel strongly about it, you should look into SOUs for those modules.

DF: I own about 17 issues. I would like to get rid of issue 234, I had brought it as the owner to a decision today, can Yves take care of it? He knows anyway best what is needed to implement the solution.

Y: Sure, I will take care of that one.

B: You should quote today’s meeting minutes as the resolution.

DF: About the Symposium: the deadline for proposals ended yesterday, but we might need to prolong it. If you know anybody that has something interesting to say, please spread the word about the Symposium. The call for sponsors is also open. http://www.localizationworld.com/lwdub2014/feisgiltt/xliffcall.html

The current sponsor of the whole FEISGILTT is CNGL. The CAL Track http://www.localizationworld.com/lwdub2014/feisgiltt/CALcall.html of FEISGILTT is also sponsored by a European project Lider. So an XLIFF specific sponsor would be welcome.

B: Meeting adjourned.

I Administration (0:00 - 0:10) A. Roll call B. Approved meeting minutes, 18 February 2014 https://lists.oasis-open.org/archives/xliff/201402/msg00033.html (approved between meetings by CFD) II XLIFF 2.0 (0:10 - 0:45) A. Public Review III is complete https://lists.oasis-open.org/archives/xliff/201402/msg00015.html 11 Feb 00:00 GMT - 25 February 23:59 GMT B. Evaluate comments collected on the tracker for PR-III for substantive vs. editorial 227 - 240 (https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker) C. Evaluate readiness for Committee Specification per schedule (https://lists.oasis-open.org/archives/xliff/201401/msg00026.html) - See step 5 (5. Approve Committee Specification (https://www.oasis-open.org/policies-guidelines/tc-process#committeeSpec ) [19 Mar]) D. SOU readiness (https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker) C. Add the media type registration for XLIFF 2.0 as a standalone template - DavidF (https://lists.oasis-open.org/archives/xliff/201402/msg00045.html) - Paul (https://lists.oasis-open.org/archives/xliff/201402/msg00046.html) III XLIFF 2.X? 3.0? (0:45 - 0:50) A. Freeze on Feature Tracking wiki? Or queue proposed post 2.0 features there? B. Do we have an official path for promoting custom namespace to supported core/module post XLIFF 2.0? IV Charter (Bryan to update site) V Sub Committee Report (0:50 - 0:55) VI Current and New Business (0:55 - )

• OASIS Open (General Membership)
• General Public