XLIFF TC Call

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, 7 January 2014 https://lists.oasis-open.org/archives/xliff/201401/msg00084.html (David's updated version)
  C. Yves' XLIFF 2.0 Okapi plugin for OmegaT https://lists.oasis-open.org/archives/xliff/201401/msg00064.html
  D  call for scribes (DavidF) https://lists.oasis-open.org/archives/xliff/201401/msg00055.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. Updated XLIFF 2.0 OASIS Standard timeline - factoring in PR III - 09 June projected date https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2558

  B. SOU Tracker https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker

  C. XLIFF 2.0 Items

Recent mailing list issues:

(new)
     1. XLIFF 2.0 Introduction seems outdated (DavidF)
https://lists.oasis-open.org/archives/xliff/201401/msg00059.html

     2. Using a local copy of xml.xsd (CFD) (Yves)
https://lists.oasis-open.org/archives/xliff/201401/msg00056.html

     3. ID constraints for the Resource Data module (Yves)
https://lists.oasis-open.org/archives/xliff/201401/msg00044.html

(existing)
     1. Fragment identification (conclusions plus Yves' Lynx examples) (Yves) (Resolved)
https://lists.oasis-open.org/archives/xliff/201312/msg00162.html
https://lists.oasis-open.org/archives/xliff/201401/msg00008.html

     2. 130 candidate annotation in Dec-17 Draft (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00164.html

     3. PR on unit order (Yves)
https://lists.oasis-open.org/archives/xliff/201312/msg00172.html

     4. PR for white spaces (Yves)

     5. Proposed solution for csprd02 (Bryan)
https://lists.oasis-open.org/archives/xliff/201401/msg00005.html

     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:

Bryan, Dave, David OCarroll, David Walters, Fredrik, Helena, Lucia, Ray, Shirley, Tom, Uwe, Victor, Yves, Joachim.

Regrets: Kevin.

Agenda

 

Bryan: meeting minutes, 7 January 2014 https://lists.oasis-open.org/archives/xliff/201401/msg00084.html (David's updated version)
Yves: I second

B: Meetings minutes approved.

 

B: Yves has created 2.0 Okapi plugin for OmegaT https://lists.oasis-open.org/archives/xliff/201401/msg00064.html. Thank you, Yves for this.

B: call for scribes (DavidF) https://lists.oasis-open.org/archives/xliff/201401/msg00055.html. Please contact David or me, we would appreciate it.

 

B: we were talking about the xml namespace (mainly the xml:space) issue (127 in the tracker), and Fredrik identified more complexity than expected. Do we have a conclusion to this issue?

F: it can have a lot of complexity if we allow it everywhere, especially in inline elements.

B: we could explicitly allow xml namespace in any element that allows extensibility.

F: do we allow extensibility on pc and mrk?

Yves: Modules are allowed on both, the problem is on mrk that is extensible by attributes.

B: and it seems that xmlspace would be useful in inline code.

F: we don’t allow extensibilty on pc anyway.

B: So the issue is only with mrk.

F: I would make xml:space default “preserve” in source and target.

B: In my experience I found the opposite, i.e. that I did not have to preserve spaces in most cases.

DF [on the chat window] we do have extensible attributes there it is actually an old problem the xml:space was always allowed by extensibility but we never had the provision for sc ec transformation I think we should define xlf:space that would be used on empty inline elements when splitting mrk and pc the issue is that our empty inline codes have non-xml behaviour so they should have a xlf:space counterpart. the xlf:space would inherit from xml:space. but it is always the same issue, because we have empty elements forming quasi spans

F: yes, and that happens because we allow mechanisms to have non-xml behavior.

DF: that's why our empty markers override translate inheritance

F: or we simply we do not allow it to change it for span.

DF: these quasi spans simply cannot pretend to work with xml:space. It cannot work, regardless of [the] default [value].

F: can we forbid specifying xml:space in inline elements?

B: From schema point of view I think we would need some gymnastics.

DF: seems as a stopgap, but very ugly stopgap.

b: If we only allow xml:space in unit or higher that would solve the resegmentation issue. That would work for the use cases I can think of.

DF: that makes sense. because actually at unit level the xml behaviour of XLIFF stops

Y: I think that is the least bad solution.

F: I agree.

T:Does that mean elements within unit always inherit xml:space from unit?

B: I think the answer is yes.

DF:[I] think it [is] likely that portions with different whitespace behavior are likely to form distinct units. We can add a constraint forbidding. xml namespace on segment and lower

B: can we do it on the shema?

T: no, I don’t think so. The extension points allow arbitrary namespaces so xml:space could be added there.

B: it is not a perfect solution, but it is the best one we can come up with.

 

B: I move that we allow xml namespace in xliff, file, group, and unit and prohibit it in segment and below

F:  I second.

Votes:

Yes: Yves, Bryan, D.Ocarroll, Dwalters, DF, Fredrik, Helena, Joachim, Lucia, Ray, Shirley, Tom, Uwe, Victor.

No: N/A

Abstain: N/A

The resolution passes unanimously.

 

Bryan:  mda id. Yves is more comfortable having it optional.

DF: I would propose required. Because optional forces external referencers to become XLIFF enrichers.

Y: It adds data when you do not always need it. So why make it required it when it does not need it?

DF: we can have a ballot with three options 1 no id, 2 req id,3 opt id and most votes wins

DF: externally referenced. but the referencer must enrich before it is able to reference

B: I move to vote

1no id.

2 req id. Bryan, Dave Ocarroll, Ray, Shirley, DF

3 opt id. Yves, DWalters, Fredrik, Helena, Joachim, Lucia, Tom, Uwe, Victor.

B: Option 3 wins with 9 votes, motion carries.

 

DF: Next topic: Make id on group required

1. Fragment identification (conclusions plus Yves' Lynx examples) (Yves) (Resolved)
https://lists.oasis-open.org/archives/xliff/201312/msg00162.html
https://lists.oasis-open.org/archives/xliff/201401/msg00008.html

These are two points :

-make group id required
-adjust uniqueness scopes in res

Yves: the first one is having the id required in group. The second one is that we noticed in the resource module, the definition does not match with the current fragid requirements.

 

DF:  exactly. also allow only one container in res. I endorsed Yves proposal. zero or one container of res data. Here is the email on the resourceData id issue: https://lists.oasis-open.org/archives/xliff/201401/msg00044.html. This is part of the overall fragid solution for res. I think group can be made CFD. we should have a roll call for res adjustment as proposed by Yves. CFD here for group.

B: CFD: I propose that we make id required for group.

DF: I second.

B: No objections. Motion carries.

B: Another ballot for the solution for the resource module. Text from Yves proposal from email [quoted above]:

The constraint for the id for

"The value of the OPTIONAL id attribute MUST be unique among all

The constraint for the id for

"The value of the OPTIONAL id attribute MUST be unique among all

Both

And

So to work properly with the URI Fragment identification we need both ids to have the following constraint:

The value of the id attribute MUST be unique among all

DF: this is just making it conformant with the approved fragid. yes/no ballot

B: Yes means adjust it, NO means leave it as it is.

Yes: Yves, Bryan, DOcarrol, David Walters, DF, Fredrik, Helena, Joachim, Lucia, Shirley, Tom, Uwe, Victor.

B: Motion carries unanimously, but Ray dropped from the call [technically an abstain].

B: P&L meeting. One of the topics is the xliff symposium, we will have a meeting next week.

 

DF: Another topic: BiDi. There was a call for dissent.

B: you sent that CFD and yves comment it. Any other thoughts on this?

DF: There was CFD, only Yves commented. We seem fine, but wanted to call it to your attention one last time, the new default value auto and the UAX #9 mapping. dropping dir from source and target. Apparently no probelms with that

Y: https://lists.oasis-open.org/archives/xliff/201401/msg00086.html

Df :, what yves posted just now.. the BIdi and segment modification are actually two different items, they partially overlap, the overlap is just in dropping dir from source and target [in resegementation PRs],

B: Do we need to approve it?

dF: no, it was agreed long ago. This is just about the overlap of the two . let us record consensus for both itmes.

B: it seems that we do not have any dissent on this.

B: AOB?

dF: csd and csprd for next week.

Df: Let us resolve remaining issues via e-mail by the end of the week, so that the editors can make changes by meeting time

B: Meeting adjourned

==========
Attendance:

Meeting Statistics
Quorum rule	51% of voting members
Achieved quorum	yes
Individual Attendance	Contributing Members: 14 of 29 (48%) Voting Members: 14 of 15 (93%) (used for quorum calculation)
Company Attendance	Contributing Companies: 9 of 14 (64%) Voting Companies: 9 of 9 (100%)