OASIS Open

See this private AI for dial in details

https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3663

Agenda

Admin

Roll call:  DavidF, Lucia, Tom, Phil, Steven R. Loomis

Apologies: Bryan, Yves.

Df:  Approve minutes from 7th Nov

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201711/msg00008.html

Tom: I second.

Df: Minutes approved.

Df: We need to discuss the issue XLIFF-72. We are lucky to have Steven, who is one of the best persons to help us with this.

1) XLIFF 2.1

- Dispose of XLIFF Version COS01 comments

Df : We have received two issues both from Mihai Nita. The first one (XLIFF-71) is basically related to how links work at OASIS, and Chet explained it. So, I propose that for this issue, we take no further action, as the system has been explained.

Tom: I second.

Df: thank you, the comment has been solved with no action.

Df: The important issue is issue XLIFF-72, also by Mihai.

Steven: the overall situation the directionality in html and markup languages has varied over time and basically it includes what you can express. I think the dir is sufficient, but what is need is the isolation control. For example, in html there is the bidi tag. In XLIff, I do not know if it should be an element or an attribute that could isolate the directionality.

Df: we are actually referencing UAX 9 Bidirectional algorithm. http://unicode.org/reports/tr9/. We allow Bidi control characters according the current UAX 9 when segments with different directionality are joined.

Steven: that is the perfect case where it should be used.

Have a look at this section of the document: https://www.unicode.org/reports/tr9/#Markup_And_Formatting

Df: the directionality solution is part of the core, so it's the same as in 2.0 and we actually cannot change it.

Steven: what might be missing I think is the support of <bdi>. The problem is if you have e.g. English content but his name is in Arabic, those tags would have an impact.

Df: We are capable of changing the directionality with inline tags on sc/ec and pc.

S: That is referencing to an external tag. But it does not give you the process, like resegmentation. Unless there is a way to know what the original code is.

Df: if the sc has dir, the span enclosed between sc and ec has to be rendered with that directionality.

S: Perhaps is there was a unicode-bdi attribute, you could communicate to the implantation directly, without having to the external element from the sc.

You can also add a note to the spec explaining this possible case.

S: I do not think there is a problem with dir as it is now in the spec, but it might not be enough to descibe the isolation behavior. I see this aslo as a problem for segmentation.

Df: what is the difference between overriding and isolating?

S: Overwriting affects things outside the box. If you have an weak directionality chars before and after, the directionality can affect outside. But if it is isolated, it will not.

Df: Sc is empty, we are talking the span between sc and ec, or even inside a pc, that span is isolated from the outside directionality if dir given..

S: the question, you have a sc ec, and between you have some Hebrew text

S: See the examples, in this webpage : https://html.com/tags/bdi/

Df: if you extract that example using sc, you would have it isolated.

S: the comma after the Arabic, without isolation, it would jump to the left.

S: you might add a note. If you want me to do it, I can write it up.

Df: In terms of the current status of the spec, if we make more than an editorial change, it would have an impact in the approval timeline. If we make an editorial note in the spec, that would be ok. The third option it would be to reply to the comment explaining our discussion and make actions extraneous to the spec.

Df: TAPICC is producing a best practices note on extraction and merging, we can add this information there too. Working on it with Jano Husarčík

S: we can also have an opinion from the editors of the Unicode and markup (http://www.unicode.org/reports/tr41/tr41-21.html#UnicodeXML) editors.

Df: What is the differencing between isolation and embedded?

S: if the text is embedded it might affect the surrounding text. Only isolation forms the "water-tight box"

Df: It would be good if we give Mihai a proper answer to their comment, if would be great if you Steven could draft it.

Df: we should agree on the solution:

1. Material changes
2. Editorial note
3. Answer to the comment, i.e. no action in the XLIFF 2.1 spec

Df: The fact that we are planning to cover it in TAPICC and in the rendering module in 2.2, shows that we are taking it seriously.

S: A bdi element/attribute can be also foresee in the future.

Df: it would need to be a new module, not to change the core.

Df: do we agree on making an explanatory note or just the third option?

S: I think if there was to make a change, I would add an attribute. I would specify that module for the future but that's a ig thing to propose. If we are not doing that, we should say something about interaction with bdi.

Df: so you would suggest an explanatory note?

S: yes, but it can be in the spec or somewhere else.

Df: it would be easier if we add this explanatory note in the TAPICC best practice. We sometimes put extraction and merging informatove material into the spec, but strictly speaking extraction/merge is out of scope of XLIFF as a standard. And this is not a best time to add a new extraction/merge note.. Other opinions from the rest of the TC members?

P: 3 is ok with me.

T: I agree

L: No action, but an action will be taken to answer the comment, won’t be?

Df: Yes, that’s right. But by “no action” I mean there is no change in the spec. We are tracting the issues wrt the XLIFF 2.1 spec..

L: Ok, thanks for the clarification. Ok for me too.

Df: Official resolution to the issue by unanimous consensus:

            No action. Comment: Steven to respond to Mihai. Actions for the TC and TAPICC T1/WG3, extraneous to spec take comment and issue into account for rendering…

Df: we can progress to a conditional request for a Special majority ballot to submit COS01 w/o changes.

I move to approve, on the condition that no more COS01 comments are received by 23:59 UCT today, the officers of the XLIFF TC requesting that OASIS TC Administration hold a Special Majority Vote to approve continuing with an OASIS Standard Call for Consent for XLIFF Version 2.1 Candidate OASIS Standard 01 (http://docs.oasis-open.org/xliff/xliff-core/v2.1/cos01/xliff-core-v2.1-cos01.html).

Phil: I second.

Votes:

Yes: Phil, Lucia, Tom, David F.

Df: The public review will end tonight (in about 7 hours). If we do not receive any more comments, I will take this unanimoulsy approved motion to the OASIS admin. They will launch the OASIS call on the 8th of January, so that we are not launching it when "no one is looking"

Df: Meeting adjourned. Happy Christmas to everyone.

Admin

- Roll call, [6 voters total]

- Approve minutes from 7th Nov

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201711/msg00008.html

Material

1) XLIFF 2.1

- Dispose of XLIFF Version COS01 comments

See all Issues affecting the COS01 version

http://bit.ly/2Bb8xvi

*** IFF all Issues resolved, we can progress to a conditional request for a Special majority ballot to submit COS01 w/o changes or COS02 with immaterial changes.

COS01 based ballot can be requested straight in the meeting, COS02 based ballot could happen electronically or after teleconference approval based on a TC agreed implementation / COS02 build/printout.

In case we agreed to address any of the open Issues with material changes we'd need to roll back to Public Review 05 and then redo CS and COS progression including collection of SOUs.

2)

XOMOS request to clarify the prefix registration process

http://markmail.org/thread/a6tgepptrs3qtns3

3)

dF requested XLIFF24TM starter document from OASIS Admin. Expect to start on this early next year..

Promotion and Liasons

- XLIFF Version 2.0 was published as ISO 21720:2017

https://twitter.com/merzbauer/status/939099106357731328

- XOMOS Progress report

- TAPICC Progress report

- TBX Progress report

AOB

Adjourn

• OASIS Open (General Membership)
• General Public