OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Modified: Regular 3rd Tue teleconference

I second


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Filip
Sent: Tuesday, December 19, 2017 1:22 PM
To: XLIFF Main List
Subject: Fwd: [xliff] Modified: Regular 3rd Tue teleconference


Hello all,


I am proposing that the below is approved as meeting minutes of record if not contested by Fri 22nd December 23:59 PST.


*This needs seconded by a voter who attended today's meeting (Lucía, Phil, Tom).*


@Steven, you are invited to review this carefully for the finer BiDi points. Your dissent or amendment requests obviously do count although you currently don't have the voting right and cannot second the approval..

Cheers and thanks



Dr. David Filip



OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122



---------- Forwarded message ----------
From: OASIS Open <workgroup_mailer@lists.oasis-open.org>
Date: Tue, Dec 19, 2017 at 6:01 PM
Subject: [xliff] Modified: Regular 3rd Tue teleconference
To: xliff@lists.oasis-open.org

Submitter's message
Minutes added, thanks to Lucía for scribing..
-- Dr. David Filip

Event Title: Regular 3rd Tue teleconference

Date: Tuesday, 19 December 2017, 04:00pm to 05:00pm WET
Location: the usual Skype for Business dial in

See this private AI for dial in details


This meeting counts towards voter eligibility.



- Roll call, [6 voters total]

- Approve minutes from 7th Nov



1) XLIFF 2.1

- Dispose of XLIFF Version COS01 comments

See all Issues affecting the COS01 version


*** 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.


XOMOS request to clarify the prefix registration process



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


- XOMOS Progress report

- TAPICC Progress report

- TBX Progress report









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

Apologies: Bryan, Yves.


Df:  Approve minutes from 7th Nov


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.


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.


Owner: Dr. David Filip
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

  • Learn more about subscribing here.
  • View the OASIS XML Localisation Interchange File Format (XLIFF) TC calendar here.
  • You may receive future notifications with updates to this event. Update the event on your calendar by accepting the changes.

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]