[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Voting membership status update Fwd: [xliff] Groups - Event "XLIFF TC Call" modified
|
Event Title: XLIFF TC Call Date: Tuesday, 16 July 2013, 11:00am to 12:00pm EDT Description
Please join my meeting. This meeting counts towards voter eligibility. Agenda
I Administration (0:00 - 0:10)
II XLIFF 2.0 (0:10 - 0:45)
B. Public review completed
III XLIFF 2.X? 3.0? (0:45 - 0:50) IV Charter (Bryan to update site) V Sub Committee Report (0:50 - 0:55) VI Current and New Business (0:55 - ) Minutes b: Yves is late or won't be able to attend. df: roll call: v, h, s,t, f, df, r, l, k, b, dw, a, u, p - regrets: y, j - quorum: 14 in attendance, 9 out of 11 voters b: aim to resolve issues re. xliff 2.0 - meeting minutes seconded by Tom. no objections. - received a private note from OASIS administrator: based on the communications re: public review comments, we are considered one of best TCs in OASIS; - we are tracking comments in the tracker of wiki; df has begun to color code to keep track of the progress; need to move quickly on these; - goal for reconciling all of the comments: 02 July - identify the statements of use: 16 July - reference implementation: Kevin has sent an email - re-approve committee draft by next meeting, August 6 - second public review: typically 15 days, it may take up to 30 August - ballot for OASIS specification: 1st part of December - it will be useful for us to go to the public review comments and find out their status; owners of the comments have to resolve the issues; - asking for clarification: - xml processing instructions (PI): Yves responded: comment #13 - we had a ballot whether or not the PI should or may be deleted and so forth; - one issue is that there is no provision on the resolution of the PI around the three comments on the ballots that said processing instructions should not be allowed in types: source and target - we have consensus around this; we are in agreement this is probably true; df: - PIs are same as CDATA and comments, e.g. core XML constructs; XLIFF is XML; we should not modify what XML can do or cannot. XML does not say PIs geve to be preserved. we shouldn't say more or less; we can explain in a note. - another interesting aspect: we should have analogical PR, they must not be misused for implementation of core or module features; we shouldn't try to add other specific instructions; b: - I agree. I will add the words "must, must not". - should we say we explicitly do not want to add language about whether PI should or should not be allowed in XLIFF file? df: - I think it can be addressed by a non-normative note. f: - if we have processing instructions in source for example; I think we need some kind of processing requirement what an agent is supposed to do when it translates? df: - propose to deal with that analogically as with comments (comments are irrelevant to content; PI are irrelevant to content). f: - describes an example use case (using revision tracking); df: - we don't provide absolute protection of PIs; people should not rely on PIs on their round trip; f: - by allowing things to exist in places where extremely difficult to preserve them, we allow something that is pretty useless; df: - maximum we can do is to warn people about using it; we can give your example; f: - wording should be PIs "may be" preserved df: - we compromised to "should be" f: - outside of segment unit or group or file or there could be a must persevered; lower down it's very doubtful that most agents would be able to preserve them; b: - just like comment we can not prohibit, or prescribe or recommend in what nature PI are to be used. df: - we can say they must not be used to compete with core and module features f: - perhaps we could have a weaker guarantee for them than should where if you place them for example source target or segment df: - not worth going on to such detail. "should" is a good solution b: - solution is to put a note similar to the notes of the XML comments. there is no guarantee that they will be preserved in a round trip; df: - we should say that user agents should preserve; however, unrealistic to expect them to survive; f: - unrealistic to expect surviving any changes to targets for example; df: - agree. b: - clear to me. we don’t restrict people from writing PI anywhere; they should be preserved in most circumstances, however it’s unrealistic to expect them to be preserved in all cases, especially in source and target (I.e. segment level). - no disagreements df: - action item: I will work on it. I will smooth it out and make it consistent with comment; b: - action item: there is a desire that a stronger example including one that deals with images is shown on the format style issues; I begin working on that; - I believe that we have removed notes and modules from segments; I believe that does not impact inline elements df: -no disagreements b: - it would be difficult, not impossible to implement format style if we don't have it on source or target - if we were to allow that module for that style on the source and target, is it as risky as other modules? - is it possible that we could revisit this to allow format style on source and target or is that too risky? f: - I think it’s too risky; you really can’t do anything; (gives example scenario); does not seem it is useful though; df: - you are in danger of breaking the object model; f: - yes. b: - ok. I will dress up the example for images by using FS and the inline elements; I will honor the restriction in my example that FS like all the other modules; it be will no longer be allowed on segments or any of its children. df: - it should be any *structural* children. b: - that's fine. df: - I need to know the status of Ryan’s modules; most risky module: resource data module; r: - I sent out proposals for change tracking, resource data and glossary modules about week ago and called for dissent for changes; received no dissent; I will do my best to make those changes today; yesterday sent out a proposal for validation module; simplify and clarify modules as soon as I don't hear any dissents back I can made changes to that module as well; df: - I responded to that; r: - I responded back; we can continue the discussion; df: - what is the story about the placeholder? r: - potentially confusing use of the term placeholder; it overlaps perhaps with the usage of inline tags; - placeholder rule is to validate that a substring appears in both source and target in same amount of times df: - you can't guarantee the number of placeholders will be the same for different languages; f: - for validation I think its ok. <gives an example scenario> r: - that was the intention df: - how do you specify? r: - placeholder is the attribute … goes in a substring; that substring could be absolutely anything; that wants to make sure that substring appears in the source is repeated in the target a certain number time; it's like the isPresent attribute; df: - it seems very ad-hoc; I don't like to call it a placeholder. r: - we can change the name. df: - it is ad-hoc; e.g. you can have "at least a number of times". r: - it is not the same as same number of times; I could specify isPresent and occurs once or twice if I wanted to; but placeholder is a short cut as it were to validate that it appears the same amount of times as in the target as in source df: I.e without specifying the number? r: - yes df: I don't have strong objection on this. f: - number is dynamic r: - I might not be able to predict what the number is; just want to match number in the source df: - we can continue on this. f: - in general the rule itself determines the number of occurrences is quite useful; because you can just have a single rule at the high level on the document that can be dynamically enforced on all children (as opposed to having single rules in every unit) df: - new syntax is much less ad-hoc; does not have complexities; I like it r: - I can make changes in time; df: - we should have the committee spec. draft by the next call; r: - how soon do you need? df: - ideally 3-4 days before the call. r: - that should be fine; I can make the updates next meet; b: - we have the timeline established for the action items; do we want to continue on clarifications regarding the tracker or do we need to switch to the ref. implementation? df: - I'd like to ask everyone to update the tracker; - help file is straight forward and simple. syntax is easy. b: - owners of actions items are requested to update the wiki. - ref implementation: we have oasis requirements to have reference implementations; we need to have those identified quickly (I.e. by next meeting); there have been a discussion by Kevin, replies by Yves; any feature that does not have an application, shall we remove that feature from the XLIFF 2.0 or can we leave it there and hope it can be implementable in future? - we would not hold hostage any features that did not have an implementation - "if it works in prod, it would have worked in test" - is this an open issues? or do we need to do any more work on this? df: - two fold issue: - we should have commitments in this meeting if we are to present to the OASIS standard before the end of year; ; Chet: if standard goes into candidate stage with large portions not implemented …;. OASIS formal requirements is 3 statements of use; not explicit about the coverage; it is not good to send specs with significant gaps in ref implementation coverage; ... I will try to have two basic implementation of every modules that we eventually want to send to XLIFF 2.0; b: - is it practical? df: - I don't think it is holding hostage; if we send to candidate stage things that are not implementation tested, it is very likely that they will need to be changed in XLIFF 2.1; we will be sending bad messaging; radical approach would be to say with core … OASIS requirement is 3 altogteher; we will have more, 2 for each feature seems reasonable; ... to have a writer and consumer; the LRC commits to do this; if you produce a writer we will build a reader/processor; that's a commitment; b: - are you looking for more commitments? df: - yes. spec that is not implemented is not a standard b: - that's true; wonder whether other OASIS TCs are this strict, df: - I haven't had any other commitments even for core. k: - clarification question about implementation: what is considered an implementation? example : prototype demo xliff 2.0 editor, would that be considered implementation. what is a valid implementation? df: - OASIS does not prescribe production level readiness; it is showing implementability rather than working production instance; k: - considering that implementation can vary in nature what needs to be done to prove it is being successfully done? df: - OASIS is not very specific here; at least one OASIS member must be among the people who state the use; they must provide statements of use in terms of formal letters saying we have an implementation and the implementation complies to all or some conformance clauses of standard; it is up to the TC to check whether implementation is real/sufficient or not; f: - <gives an example scenario explaining a tool> df: - having some implementation is better than no implementability test at all; f: - deadline for finishing implementation? df: - we must provide verified/accepted statements at the point when we want to proceed to the candidate standard; b: - 17th of September; we need to identify these applications now f: - I can't commit today but should be fine in two months df: - everyone should look into implementations no matter how small; I will start tracking the coverage; b: - I'll commit re: xliff roundtrip tool, but not today. df: - I'd start tracking these commitments after the 1st August meeting and report in 2nd meeting in August. b: - no new business. 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 |
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:20130719T000000Z
DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20130716T110000
DTEND;VALUE=DATE-TIME;TZID=America/New_York:20130716T120000
SEQUENCE:1
SUMMARY:XLIFF TC Call
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 \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 \n \n Access Code:
905-529-225\n Audio PIN: Shown after joining the
meeting\n Meeting ID: 905-529-225\n\nAgenda: \n I
Administration (0:00 - 0:10)\n A. Roll call\n B. Approve
previous meeting minutes, 02 July 2013
https://lists.oasis-open.org/archives/xliff/201307/msg00055.html\n
C. Completed ballots\n 1. Move modules and notes out
of segment - passed\n 2. Several issues resolved via
Call For Descent (CFD)\n D. Worth mentioning, the XLIFF TC
received a very positive compliment from Chet regarding the
way we are managing the comments from our public review.
Thank you everyone.\n\n II XLIFF 2.0 (0:10 - 0:45)\n A.
Actions required to stay on track according to our timeline
https://lists.oasis-open.org/archives/xliff/201306/msg00042.html\n
1. General approach to properties and sub-properties
[needed for comments 021 and 053]\n 2. Reference
Implementations for XLIFF 2.0 [identify by 16 July] (Kevin)
https://lists.oasis-open.org/archives/xliff/201306/msg00040.html\n\n
B. Public review completed\n 1. Comments are tracked
on the wiki: review assignments and status\n
https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker\n
2. Review progress on comment replies and
updates\n\n III XLIFF 2.X? 3.0? (0:45 - 0:50)\n 1.
Freeze on Feature Tracking wiki? Or queue proposed post 2.0
features there?\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 - )\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=35781
UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=35781
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]