[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - Event "XLIFF TC Call" modified
|
Event Title: XLIFF TC Call Date: Tuesday, 17 December 2013, 11:00am to 12:00pm EST 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 This meeting counts towards voter eligibility. Agenda I Administration (0:00 - 0:10)
A. Roll call 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 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: Recent mailing list issues:
2. Comments on Fragment Identification (Yves)
3. Re-ordering of inline codes (Yves and DavidF)
4. URI in XLIFF2 (Yves)
5. Segmentation Modifications (Yves)
6. Modules attributes in ec vs em
7. Namespace in Validation Module (is this fixed?) 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 140), 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 <bdi> or <bdo> F: The only reason is that it is too late. The other way would be to have the control characters in <cp> D: They would be represented as hex codes in <cp> with a specific set of PRs for the subset representing control characters? F: it is not really beautiful, <cp> was supposed to carry just the characters that are not allowed in XML. 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 <source> and <target>. 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 <source> and <target>. I would make two different calls for dissent.. 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. Owner: Bryan Schnabel 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 NOTE: The best way to keep your desktop calendar updated is to subscribe to the Group calendar. |
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:PUBLISH
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:America/New_York
BEGIN:STANDARD
DTSTART:20001029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T060000Z
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000402T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T070000Z
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:CONFIRMED
TRANSP:OPAQUE
DTSTAMP:20131220T000000Z
DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20131217T110000
DTEND;VALUE=DATE-TIME;TZID=America/New_York:20131217T120000
SEQUENCE:1
SUMMARY:XLIFF TC Call
DESCRIPTION:\n \n\n Please get the dial in information from our private
Action Item here:\n\n \n\n
\n\n https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3663\n\nAgenda:
\n I Administration (0:00 - 0:10)\n\n A. Roll call\n B.
Approve previous meeting minutes, 03 December 2013
https://lists.oasis-open.org/archives/xliff/201312/msg00068.html\n
C. Ballot passed: Mandate of the Promotion and Liaison
Subcommittee is extended until December 31, 2014.\n
https://lists.oasis-open.org/archives/xliff/201312/msg00056.html\n
D. Comment to be resolved:\n New value for datatype:
reqif (Gerhard Schneider)\n
https://lists.oasis-open.org/archives/xliff-comment/201311/msg00001.html\n\n II
XLIFF 2.0 (0:10 - 0:45)\n\n A. Public Review II ended
October 5\n\n 1. Public Review Comments are tracked
here
https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker\n\n
2. Timeline
https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201309/msg00029.html\n
If PR III:
https://lists.oasis-open.org/archives/xliff/201310/msg00072.html\n\n
B. SOU Tracker
https://wiki.oasis-open.org/xliff/XLIFF%202.0%20SOU%20Tracker\n\n
C. XLIFF 2.0 Items\n\n 1. Review of unresolved tracker
issues:\n a. 100 - Suggest fleshing out samples
(Bryan)\n b. 103 - splitting of modules and extended
elements (Fredrik)\n c. 104 - location of "info"
elements (, modules, etc.) (Fredrik)\n d. 105 -
Namespace in Validation Module (Ryan)\n e. 107 -
subState and state='initial' (DavidF)\n f. 110 -
xml:space (DavidF)\n g. 111 - Proposed changes to
matches module (DavidF)\n h. 113 - Improve sub-flows
(DavidF)\n i. 114 - id values constraint specified
in two places (DavidF)\n j. 118 - no link between
type and subType values for inline codes (DavidF)\n
k. 119 - definition and spelling of 'quot' type (DavidF)\n
l. 120 - wrong agent? (DavidF)\n m. 126 - ref
in mrk (DavidF)\n n. 127 - xml:lang and xml:space
(Bryan)\n o. 130 - Translation Candidate Annotation
(DavidF)\n p. 135 - extensibility wording
(DavidF)\n q. 137 - XLIFF as a processing format for
CAT tools (DavidF)\n r. 138 - schema ambiguity in
core and matches (Tom)\n s. 141 - XLIFF: prefix in
size restriction (Fredrik)\n t. 143 - MUST NOT in
spanning description (DavidF)\n u. 144 -
inconsistent PRs for cloning/replicating codes with copyOf
(DavidF)\n v. 145 - improve the appearance of schema
files (Tom)\n w. 147 - mrk translate outside the
content but in scope (DavidF)\n x. 149 - Element
names (DavidF)\n\n Recent mailing list issues:\n\n 2.
Comments on Fragment Identification
(Yves)\n https://lists.oasis-open.org/archives/xliff/201312/msg00000.html\n\n
3. Re-ordering of inline codes (Yves and
DavidF)\n https://lists.oasis-open.org/archives/xliff/201311/msg00154.html\n\n
4. URI in XLIFF2
(Yves)\n https://lists.oasis-open.org/archives/xliff/201311/msg00131.html\n\n
5. Segmentation Modifications
(Yves)\n https://lists.oasis-open.org/archives/xliff/201311/msg00137.html\n latest
comment from Yves "I've put a "TBD" flag in the
bi-directionality mapping paragraph since this is under
discussion."\n\n 6. Modules attributes in ec vs
em\n https://lists.oasis-open.org/archives/xliff/201312/msg00040.html\n\n
7. Namespace in Validation Module (is this
fixed?)\n https://lists.oasis-open.org/archives/xliff/201312/msg00089.html\n\n III
XLIFF 2.X? 3.0? (0:45 - 0:50)\n\n 1. Freeze on Feature
Tracking wiki? Or queue proposed post 2.0 features
there?\n\n 2. Do we have an official path for promoting
custom namespace to supported core/module post XLIFF
2.0?\n\n IV Charter (Bryan to update site)\n\n V Sub
Committee Report (0:50 - 0:55)\n\n VI Current and New
Business (0:55 - )\n \nGroup: OASIS XML Localisation
Interchange File Format (XLIFF) TC\nCreator: Bryan Schnabel
URL:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=36584
UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=36584
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]