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
==========
Agenda:
I Administration (0:00 - 0:10)
A. Roll call
B. Approve previous meeting minutes, 03 December 2013 https://lists.oasis-open.org/archives/xliff/201312/msg00068.html
C. Ballot passed: Mandate of the Promotion and Liaison Subcommittee is extended until December 31, 2014.
https://lists.oasis-open.org/archives/xliff/201312/msg00056.html
D. Comment to be resolved:
New value for datatype: reqif (Gerhard Schneider)
https://lists.oasis-open.org/archives/xliff-comment/201311/msg00001.html
II XLIFF 2.0 (0:10 - 0:45)
A. Public Review II ended October 5
1. Public Review Comments are tracked here https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker
2. Timeline https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201309/msg00029.html
If PR III: https://lists.oasis-open.org/archives/xliff/201310/msg00072.html
B. SOU Tracker https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker
C. XLIFF 2.0 Items
1. Review of unresolved tracker issues:
a. 100 - Suggest fleshing out samples (Bryan)
b. 103 - splitting of modules and extended elements (Fredrik)
c. 104 - location of "info" elements (
Recent mailing list issues:
2. Comments on Fragment Identification (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00000.html
3. Re-ordering of inline codes (Yves and DavidF)
https://lists.oasis-open.org/archives/xliff/201311/msg00154.html
4. URI in XLIFF2 (Yves)
https://lists.oasis-open.org/archives/xliff/201311/msg00131.html
5. Segmentation Modifications (Yves)
https://lists.oasis-open.org/archives/xliff/201311/msg00137.html
latest comment from Yves "I've put a "TBD" flag in the bi-directionality mapping paragraph since this is under discussion."
6. Modules attributes in ec vs em
https://lists.oasis-open.org/archives/xliff/201312/msg00040.html
7. Namespace in Validation Module (is this fixed?)
https://lists.oasis-open.org/archives/xliff/201312/msg00089.html
III XLIFF 2.X? 3.0? (0:45 - 0:50)
1. Freeze on Feature Tracking wiki? Or queue proposed post 2.0 features there?
2. 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 - )
==========
Minutes:
Attendance: Fredrik, Helena, Joachim, Kevin ODonnel, Lucia, Uwe, David OCarroll, David Filip, Yves, Brian, Tom Comerford, Ray, Victor Amaya, David Walters.
Bryan: Welcome to David O’Carroll and Ray. We will start with the TBA changes mentioned by David.
I move to approve previous meeting minutes, 03 December 2013 https://lists.oasis-open.org/archives/xliff/201312/msg00068.html
David : I second.
Bryan : Meeting minutes approved.
Bryan: The P&L ballot approved to renew the mandate of the SC.
Bryan: We have a comment from the public comment list on the XLIFF 1.2 @datatype attribute..
Yves: there is a list of current values, and any user defined value can be used, using the x- prefix mechanism.
David: We should respond that this attribute does not have an equivalent in the currently developed spec and that user defined x- prefixed value is the advised solution for XLIFF 1.2.
Bryan: I have enough information. I can formulate the response.
David: In previous meetings and on mailing list, we identified the key unresolved issues. These might be too big for the last meeting of this year, so I’d like to make some progress on small issues, so that only the big ones remain open.
David, I have a list of minor issues that if I do not hear any objection can be summary approved in this meeting: https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker
I invite everyone to express their objections if they feel that any of the change/solution needs more scrutiny.
I believe that the following are minor issues that have been resolved in the current WD and can be summary approved in this meeting:
102, 105, 107,110, 111, 113, 114, 118, 119, 120, 126, 130, 137
[David goes through the proposed group of comments one by one and explains how these are resolved in the wd03 as of Dec 17, 2013].
[102 and 105 did not register any objections.]
Yves objects to including 107.
[107 is out of the list, as the solution needs to be reviewed by Yves.]
[110 did not register any objections.]
[Re 111:]
F: Simply Id ref is enough.
D: OK, I take 111 out of the group for summary approval as it needs to be resolved in sync with the fragment identification issue.
[113, 114, 118, 119, 120, and 126 did not register any objections.]
[Re 130:]
Yves: This type of Annotation was added between csprd01 and csprd02, do we really need a translation candidate annotation?
David: I will take 130 out from the group for summary approval.
[137 did not register any objections.]
David: This is the resulting list of minor items to be approved: 102, 105, 110, 113, 114, 118, 119, 120, 126, 137.
D: I move to approve that the above comments have been resolved in the wd03 as of Dec 17:
B: I second.
D: I call for votes:
Yes [10]: Victor, Helena, Tom, Fredrik, David Filip, Lucia, Kevin, Bryan, Uwe, David Walters.
Abstain [2]: Yves, Joachim,
D: Motion carries. Thanks to all voters.
D: I will let Bryan to see which of other issues could be eventually resolved in the remaining time.
B: Fragment identification and uniqueness of Ids is the most important issue, but maybe too big to be addressed today. I will ask the owners of the open issues to speak up.
D: Before we start, I just remembered another minor issue, the use of the Xliff prefix in the size restriction (comment 141), that can be a minor issue. Fredrik, is there any reason to keep xliff: instead of xlf:?
F: No reason, it can be replaced
D: Great, so I can take it.
B: Yves, does it satisfy your concern?
Y: It does.
B: David, do you call for dissent?
D: I do
B: No dissent registered.
D: Good, I will implement it after the meeting.
B: The fragment identifiers?
D: We could benefit from the discussion on directionality. We have Helena and David Walters here.
F: we can break the issue into smaller sections.
D: Adding the value auto and making it default seemed to receive no dissent on the mailing list
F: Yes, everyone seemed to be OK with that.
D: We can table isolates and overrides
F: We will need to introduce inline tags, but then introducing dedicated elements for that.
D: that was my thinking, why not having a or
F: The only reason is that it is too late. The other way would be to have the control characters in
D: They would be represented as hex codes in
F: it is not really beautiful,
D: Why not forbid joining segments that have different directionality?
Y: why not? It is commonly needed when merging back.
F: You can also remove the directionality from the segments, and it will solve the issue.
D: So our markup solution is not expressive enough to have all characters.
J: how can you have the conflicting directionality?
F: two directionality attributes.
D: the directionality is normally triggered by the language via script.
D: I agree with Fredrik that it is too late to have a solution completely without control characters.
F: An example would be a paragraph in Arabic that starts with an American name.
J: we make the language based assumption, if the language is normally LTR direction; we assume that that is the normal display.
F: I am leaning to having the solution of removing the directionality in the levels that are lower than unit, that would solve the problem.
D: Also in inline elements?
F: no, only from and
D: what about the overrides? For certain scenarios (partnumbers) you might need to enforce directionality even against strong characters.
F: We need them. We can have them in spans from the beginning.
D: So, extractors should be clever enough to extract that information using inline codes, so that the control characters can be avoided.
F: So, if you see that something is a product number, street, etc, you can always protect it. So it will not suffer from the directionality issue.
D: should we add an explanatory note for that?
B: Yes.
D: we had consensus on adding the third value “auto” that will become the default and killing the directionality attribute on and
D: Can you implement that in spec, Fredrik?
F: I am not sure how much time I have.
B: New business?
B: do we have a subcommittee meeting or should we continue with the discussion in that hour?
D: we continue with the discussion.
Meeting adjourned
[The following discussion happened after the meeting was adjourned and lost quorum, this is just FYI]
Bryan: should we talk about fragment identifiers?
D: Combining files, that is one of the part issues of that big issue. Whether are allowed to combine files.. What do you think about it?
D: Yves is pushing UUIds for files. These would be handy if you are combining files. I had consensus with Fredrik. that this is not allowed and if people do it, that is their own private matter and the XLIFF that goes back or further must be as if the combining or splitting did not happen.
B: It seems like a fundamental Yes/no question, and I am not in a position to decide myself on it yet.
D: Another, if we allow references between units, As long as you allow crossreference between units you will need to keep the wjole xliff in memory, this seems crazy, that was your point Dave, right?
DOC: Yes, if we are allowed to reference another file internally, then you have to have all the other files available to you.
J: I kind of agree, we are experiencing a crossreferencing issue at the moment. I would be in favour of forbidding this.
DF: Referencing without context it is always constrained to the unit. This is the same in all three proposals.
We will continue the discussion on the mailing list.
DF: An issue that I forgot to mention in the main meeting. I think it is a tricky one. The xml:lang and the xml:namespace attributes. They are allowed, as Yves pointed out, by the wildcard even in places where we do not allow them explicitly. Comment number 127.
Bryan: I think we agreed on something, but I cannot recall it.
DF: As an extension, they can be killed and therefore the inheritance would be broken. So, we have two solutions: either we take them into account or we forbid them. I cannot decide which of the two is uglier.
Bryan: I think forbidding them would be worse. A warning can be better.
DF: I think it is ugly and dangerous.
Bryan, my thinking was that they are not allowed if the wild card is other
DF: That would be also my intuitive inclination, but the wild card other only excludes the xliff core namespace. It feels awkward that xml: is allowed, nevertheless it is so. Maybe a solution would be to make our own xliff land and space that would behave exactly as xml land and space, but being our own they would be excluded by other..
DF: Informal discussion adjourned.
==========
Attendance:
Meeting Statistics |
Quorum rule |
51% of voting members
|
Achieved quorum |
yes |
Individual Attendance |
Contributing Members: 14 of 29 (48%) Voting Members: 12 of 13 (92%) (used for quorum calculation)
|
Company Attendance |
Contributing Companies: 8 of 14 (57%) Voting Companies: 8 of 9 (88%)
|