[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, 14 January 2014, 11:00am to 12:00pm EST Description Please get the dial in information from our private Action Item here:
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. 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)
2. Using a local copy of xml.xsd (CFD) (Yves)
3. ID constraints for the Resource Data module (Yves)
4. id scopes again (DavidF)
https://lists.oasis-open.org/archives/xliff/201401/msg00075.html
5. Proposal to add REQUIRED id (NMTOKEN) in mda (Bryan)
https://lists.oasis-open.org/archives/xliff/201401/msg00080.html
6. Segmentation modification - finalize (DavidF)
https://lists.oasis-open.org/archives/xliff/201401/msg00085.html
(existing)
2. 130 candidate annotation in Dec-17 Draft (Yves)
3. PR on unit order (Yves) 4. PR for white spaces (Yves)
5. Proposed solution for csprd02 (Bryan)
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: 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) 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) These are two points :
-make group id required 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 Owner: Bryan Schnabel Group: OASIS XML Localisation Interchange File Format (XLIFF) TC Sharing: This event is not shared to any other groups. 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:20140117T000000Z
DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20140114T110000
DTEND;VALUE=DATE-TIME;TZID=America/New_York:20140114T120000
SEQUENCE:2
SUMMARY:XLIFF TC Call
DESCRIPTION:\n Please get the dial in information from our private
Action Item
here:\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, 7 January 2014
https://lists.oasis-open.org/archives/xliff/201401/msg00084.html
(David's updated version)\n C. Yves' XLIFF 2.0 Okapi
plugin for OmegaT
https://lists.oasis-open.org/archives/xliff/201401/msg00064.html\n
D call for scribes (DavidF)
https://lists.oasis-open.org/archives/xliff/201401/msg00055.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. 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\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 Recent mailing list
issues:\n\n (new)\n 1. XLIFF 2.0 Introduction seems
outdated
(DavidF)\n https://lists.oasis-open.org/archives/xliff/201401/msg00059.html\n\n
2. Using a local copy of xml.xsd (CFD)
(Yves)\n https://lists.oasis-open.org/archives/xliff/201401/msg00056.html\n\n
3. ID constraints for the Resource Data module
(Yves)\n https://lists.oasis-open.org/archives/xliff/201401/msg00044.html\n\n
4. id scopes again
(DavidF)\n\n https://lists.oasis-open.org/archives/xliff/201401/msg00075.html\n\n
\n\n 5. Proposal to add REQUIRED id (NMTOKEN) in mda
(Bryan)\n \n https://lists.oasis-open.org/archives/xliff/201401/msg00080.html\n \n
\n \n 6. Segmentation modification - finalize
(DavidF)\n \n https://lists.oasis-open.org/archives/xliff/201401/msg00085.html\n \n (existing)\n
1. Fragment identification (conclusions plus Yves' Lynx
examples) (Yves)
(Resolved)\n https://lists.oasis-open.org/archives/xliff/201312/msg00162.html\n https://lists.oasis-open.org/archives/xliff/201401/msg00008.html\n \n
2. 130 candidate annotation in Dec-17 Draft
(Yves)\n https://lists.oasis-open.org/archives/xliff/201312/msg00164.html\n \n
3. PR on unit order
(Yves)\n https://lists.oasis-open.org/archives/xliff/201312/msg00172.html\n \n
4. PR for white spaces (Yves)\n \n 5. Proposed
solution for csprd02
(Bryan)\n https://lists.oasis-open.org/archives/xliff/201401/msg00005.html\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 \n \n \n \n \n \n \n
\n \n \n \n\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=37054
UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=37054
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]