[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - Event "F2F dial in session" modified
|
Event Title: F2F dial in session Date: Monday, 10 June 2013, 09:00am to 10:00am EDT Location: London Description
Please join my meeting. Agenda 2.00 (local London time) Session 2: TC Remote dial in teleconference
3:30 Session 3: Public info session from 3.30 till 5.00 (Note, we have no requests from people wishing to attend a public session and will therefore use this time to tackle leftover items from the morning session. I imagine agents and processes will be a likely candidate) Minutes 2.00 Session 2: TC Remote dial in teleconference Tom joins the call through the gotomeeting system. B: Approve the meetings. Anybody seconds? Y: I second. B: We have had a fruitful meeting this morning. We are going to present a summary now: Primary categories: Freedik: Re-segmentation 9:30 – 10 (F) § Option 1 – if segment has extension -> no reseg § Option 2 – if segment has extension -> seg and remove § Option 3 – add canReseg in unit (tools have to set the attribute), if yes and extension -> undefined behavior. § Option 4 – Move meta to unit and use <mrk> to “place” them in the content. B: We went around the room and option 4 was the preferred one followed by option 3. We can have a roll call now. Y: I think one of them implies major changes, so we would need more time to decide. D: We can have a 7 days time elapse vote. B: I agree on that, does somebody second? D: I second. F: the risk we are facing now is having more comments in the second review.
Extensibility: Ryan’s requests (segment and glossary) 10 – 10:30 (R). D: We had a consensus on having extensibility through mda:. R: Segmentation. Glossary (or, can modules extend modules? Odd that matches is the only module extended by mda:). Glossary 10:30 – 11 (F), Add id (to point from <mrk> type term) on <glossentry>; and add extensibility (elements and attributes) – not on children. D:We have also discussed: -Add and id attribute in glossentry. -Allow extensions in glossentry (elements, attribute). -Remove glossary in <file>.
Y: I am not sure about removing. Adding features is not a problem, but deleting them might bother some people for whatever reason. B: We have consensus about the first two, we can do a vote rollballot. D: I propose to have glossary remove from file to have a roll ballot on that.
Next session : Agents and Processes 11 – 12 (D) D: we presented different agent profiles that can be tested. We almost reached consensus on agents types. Extractor-Merger, Enricher and Modifier. We put together two previous categories: translation editor and modifier into the Modifier. This is allowing to group tests per type. § Need examples § Our charter calls for test suite (note: we will allocate extra time in the Session 3 for any of these that need extra time, along with other review items that need time) B: We might be discussing this topic during the last session again as we will not be having a public session.
B: We can see now the comments’ state in the wiki.
B: Does anybody want to comment on any of the comments? Y: (31)We have a text from ITS addressing that topic. [Yves shows the processing requirements for unit]. B: (13) Yves says “MAY” in the comment about preserving proc. instructions, and I think it should be a “MUST”. Y: I do not agree with that. D: it should be a should. T: the xml perspective on processing instructions. But when we are translating something, there is not need to have PI in the target. B: May, should, must? T: I think “May” would be the correct one from a XML point of view. Y: It is like an XML comment at the middle of the content to me. So it should be a “MAY” instead of “SHOULD”. D: I think it is OK for comments. Y: Anything within the unit can be a problem. B: What do you propose? Y: We should address this point somehow and somewhere. D: the definition of Proc. Instr. does not say anything about preserving them.
B: Any other issues on the comments section?
B: So the next step was talking about the next steps: The big risk of the second session of comments is that we cannot make changes, so if the found issue is critical we might need to restart the standards approval circle. - Timeline for progression toward XLIFF 2.0 OASIS Standard 12 -12:30 o Goal for reconciling each comment: [02 July] o Statements of Use [identify by 16 July] [Note: Tom will join us in the afternoon dial-in session to discuss potential solutions he’s working on] § Must have a statement of use for each major feature? § Test Suite (1 application vs. ecosystem of tools) § Reference Implementation [identify by 16 July; roll out by 06 Aug?] § One implementation that touches each feature § Candidates? o Re-approve Committee Draft (that reflects resolved comments, https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft ) [06 Aug] o Second Public Review, 15-day [12 Aug – 30 Aug] o Approve Committee Specification (https://www.oasis-open.org/policies-guidelines/tc-process#committeeSpec ) [17 Sep] o Approve OASIS Standard (https://www.oasis-open.org/policies-guidelines/tc-process#OASISstandard ) [17 Sep – 09 Dec] § Submit Candidate Specification [17 Sep] § Public Review of Candidate Specification (60 days) [24 Sep – 22 Nov] § Ballot for OASIS Specification approval [25 Nov – 09 Dec] B:Any other comments about the timeline? We can start talking about “statements of use”. We have a toolkit that you started.
D: We need test suite to have the tools tested for conformance. The test suite is not an obligation; it is a collection of examples. Anyone who would like to claim conformance, we would have a test suit that would help us to provide that. If we want to have a good practice implementation we need this type of mechanism. B: Yves is showing the “statement of use” by OASIS, they do not seem difficult to accomplish. D: If we lower the barrier it would be easier to get the statements, but the usefulness would not be the same. I think this is the time to start collecting them. Y: where are our conformance clauses? I can only see one in H.1.7 [in the spec]. I think we should read closely to the “statement of use” definition, because they talk about conformance clauses, and it is not really clear in our spec where they are.
D: After having approved the proposed terminology about agents, I can start adding in the spec in parts like matches “agents should ….” . Y: [shows the “processing Requirements” in B.1.3.4.]. We have reached the problem that we are testing applications not the format, and our work is only to define the format. That is the case that Rodolfo raised some time ago. D: the OASIS requirements are very blurred and that can be double-edged. I think every feature should receive a statement of use, otherwise it should not be in the standard. F: Does it mean that we should delete features if we do not have a statement of use. D: I think we should do that. B: We are in a situation where we have to decide on how strict we want to be in order to have our spec passed. Either we become very strict and start discarding features that do not have a statement of use, we can also starting collecting statements of use and people send us screenshots showing that they implemented some features. B: we do not have much time for all this. We are also driven by calendar. J: It is a circular thing: we might not get implementations until the spec becomes stable. B: Do we really statements of use for every feature? D: I would try to aim for all of them and then see what we start getting. We need to identify a real structure to have examples. An OS tool would be adequate for this. And, Kevin, do you have something at Ms that you could share? K: I am not sure we could share it. D: You just need to demonstrate it, no need of breaking any disclosure agreement in your side. Y: I do not think it is reasonable for this spec if we want to keep our timeline. f: The risk is that people might ignore them. Y: if the tools are not implemented features, what is the point of having those features in the spec?
B: we can say that the date is no reasonable and extend it to accommodate the statements of use, or say that the statements of use is not reasonable. Do we think that the date is reasonable? [All agreed.] K: If the date goes away, the risk is bigger. B: We stick with that the date. If we continue pushing the date away, it will disappear from our eyes. D: People outside think that it takes too long to develop a standard. I do not think that is the case, but unfortunately that is their perception. Y: I think we should target it but it is not reasonable. B: What happens if we miss it? f: we miss it, that is. B: We are very good about talking about timeline, but not about sunset the features that are not usable (deprecating features). Binary unit was a good example. Maybe it is not a good idea to kill something if we just think that is not being implemented. D: we cannot predict which features are going to be implemented from which tool. I would say that a gold standard should have every feature implemented with a statement of use. We can have a percentage limit. B: that means that if by December we do not reach that percentage we would not be ready. D: Yes. B: How many features do we have? Y: they are Processing requirements, not features. I have seen a case of PR that are not really PR, but Schema validation requirements. E.g. Processing requirements at C.1.2.2. F: Yes, I have seen those cases. D: Should we remove them? Y: Well, it needs rewording at least. Because those are not processing requirements. A person going through a tool and checking all these things it is very time consuming. J: I am ok with implementing them. Y: you will have to go through all the processing requirements, and that is going to take a lot of time. There are 62 processing requirements. D: Out of those are complex ones, some of them are not. If we eliminate those that are about dependencies and schema, there might not be that many.
B: Tomorrow we have the symposium and people would be asking us. T: I have been through the proc. Req., and some of them can be just validated against the schema. B: We should reword those. D: Yes, we should reduce the proc. requirements and we could have a better idea about the work needed in terms of statements of use for the proc. Requirements. [coffee break] B: Would it be the best use of our time to go through all them? We might not have time to David’s agent topic. D: I think they are totally connected. B: Does everybody agree? [Yes. Yves makes changes directly on the spec, please refer to that document]. Another section “constraints” is created to substitute the Proc. Req. That can be validated using the schema. There are 24 proc. requirements that can be converted into constraints. B: How does the 6 Dec still looks now? Y: Moving that to the schema takes time. D: I will do it. B: What should we say tomorrow? 6Dec. For Chritsmas! D: We have some minutes left, we can agree on the agents list. B: what do you suggest? D: Extractor, merger, modifier, (enricher). Enricher adds metadata, e.g. inserting matches. I will do it together with the pdf modification for the contraints. I proposed for electronic ballot that processing requirements SHOULD be preserved. B: I second. Thank you all for your participation, the organisers, the note takers.
Meeting adjourned. Owner: Bryan Schnabel Group: OASIS XML Localisation Interchange File Format (XLIFF) TC Sharing: This event is not shared to any other groups. |
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:20130616T000000Z DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20130610T090000 DTEND;VALUE=DATE-TIME;TZID=America/New_York:20130610T100000 SEQUENCE:1 SUMMARY:F2F dial in session LOCATION:London DESCRIPTION:\n Please join my meeting.\n https://www1.gotomeeting.com/join/905529225\n Use your microphone and speakers (VoIP) - a headset is recommended. Or\, call in using your telephone.\n France: +33 (0) 182 880 780\n Germany: +49 (0) 892 2061 159\n Spain: +34 911 23 0850\n Sweden: +46 (0) 852 500 612\n United Kingdom: +44 (0) 203 535 0611\n United States: +1 (773) 945-1031\n 
\;Access Code: 905-529-225\n Audio PIN: Shown after joining the meeting\n Meeting ID: 905-529-225\n\nAgenda: \n 2.00 (local London time) Session 2: TC Remote dial in teleconference\n\n \n Administration (roll call\, approve previous meeting minutes https://lists.oasis-open.org/archives/xliff/201306/msg00002.html ) 2 - 2:10\n \n Summary of the morning session 2:10 &ndash\; 2:20\n \n Review PR comments\, assignments\, and progress 2:20 &ndash\; 3\n \n Review timeline and next steps 3 &ndash\; 3:30\n \n Additional topics\n \n \n Test Suite for XLIFF 2.0\n \n \n Comprehensive applications vs. eco system of tools?\n \n (optional branch discussion: Consider certification authority for XLIFF 2.0 compatible tools?)\n \n (optional branch discussion: Independent body that could certify compliance of XLIFF 2.0 tools\, to encourage correct adherence to standard)\n \n \n \n Formalizing the role of extensibility as launch pad for future XLIFF Core or Module features - https://lists.oasis-open.org/archives/xliff/201305/msg00022.html\n \n \n\n\n 3:30 Session 3: Public info session from 3.30 till 5.00\n\n (Note\, we have no requests from people wishing to attend a public session and will therefore use this time to tackle leftover items from the morning session. I imagine agents and processes will be a likely candidate)\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=35662 UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=35662 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]