[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, 06 August 2013, 11:00am to 12:00pm EDT Description
Please join my meeting.
France: +33 (0) 182 880 780
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 Atttendance: Victor, Tom, DavidF, Bryan, DavidW, Asanka, 6 members (4 voters) 4 voters out of 13 means a non-quorum working meeting LoA: Helena, Uwe, Yves df: We have 13 voters so we need 7 voters to achieve quorum. we have six people in the call; so it’s impossible. let's jump into the spec. - going quickly through the html version of the spec that was sent via email. - we managed to make the keywords uppercase; - comments tracker (wiki): green colour = solutions implemented; - issue #039: rewrite of the normative language from the point of view of processes, agents etc.; this was decided on the f2f; we also decided to change many of the PRs to constraints. - we have agreed definitions for processes and agents; also for enriching, extraction, merging and so on; - we have defined xliff documents; we are using those definitions throughout the spec; mainly in PRs; but also in conformance section; - we have to add normative references in a separate section; we had to add html5 reference; fix note on datetime references and so on; - Tom has developed a report for catching occurrences of non-uppercased keywords; this will ensure spec will be of high quality; this is a major effort; - the tree structure was changed based on one of the public review comments; basically Yves commenting on the tree structure ... and on the last TC we decided that we are going to enforce elements order; it was quite clear consensus; tree is currently not up to date; Tom has developed some automation scripts to make the trees compliant with the current specification and the schemas listings; Tom automates the schema listing. t: I will have a script to update the tree structure soon. df: In skeleton there was a minor change based on the public review comments: there were duplicate mechanisms ... to reference to external skeleton; now the only mechanism is on the skeleton element. the skeleton element must be empty if the reference to external skeleton element is used; - group is recursive; at least one unit must exist in every file. - major changes happened in the segment level; due to comment on not having regimentation PRs; in the f2f it was decided that segments need to get uncluttered to allow real re-segmentation; now the segment is clear - it only allows source and target; attributes are also pretty simple: id, translate, approved, state, and sub- state. - it is clear that 'state' and 'approved' have some relationship between each other; it wasn't clear what; it was commented by Ryan & Yves; I.e. lack of PRs regarding the state and approved; I have proposed a solution and implemented it; since TC hasn't had consensus or a ballot, I have marked it as yellow; not clear it's a satisfactory solution; b: Are you asking for dissent? df: I was thinking of a ballot today; I can call for dissent giving two extra days or so; - solution: making the approved attribute required. it is easy to maintain by everyone; I though it should have priority over the state attribute; state attribute has four states; I added constrains that are defining the relation between them; - constrains: state must not be final iff approved is no and state must not be initial iff the approved is set to yes; - some have suggested collapse the state and the sub-state; I don't think it’s a good idea due to granularity issues; - sub-state and state are in a relationship; we need to have consensus on sub-properties and master properties; Ryan was in the discussion; lead to the conclusion that sub-properties should be made dependent on the master property by one constraint and one PR; - constraints: you must not use the sub-property unless you specify the master property; this is true for sub-state, sub-fs, sub-type everything; - PR was not clear; whenever someone updates state; they must also update or delete the sub-property; same should be true for all pairs of property and sub-property; - it might be possible some of the sub-states are still valid after the update; this is just a special case of update; if you don't know about the sub-property you need to clear the sub-property; - this is a major decision; conclusion was clear; - because of some pending decisions and due to not having quorum today we cannot send the spec to the 2nd public review; we should finalise the spec this week; today we can decide informally whether any of the pending decisions can be resolved by calls for dissent or whether we need ballots; - like to know what you think about the proposed solution of approved and state b: I agree it’s a good solution; t: Looks good to me as well; df: Missing PR regarding re-segmentation is a major blocking issue; it should be pretty simple though; - can we have an informal _expression_ of opinion on the general sub-property solution? sub-ptoprties have the same PR and constraint. dw: I have some concern about this sub-type; where sub-property has to be updated; sub-type may be the same value as it was before after the type changed, though it is considered to be updated; that's not really process driven; df: If you are an agent changing the type and if you don't know anything about the sub-types, then you need to delete them; if you happen to know the sub-property values, you may update it; sub-property may be the same; it’s up to the private authority that specified the custom values; dw: It is somewhat confusing; but ok. df: If you are getting a file with state and sub-state; if you don't know anything about the sub-state machine, and if you need to change the state you have to kill the sub-state; otherwise you have to update the sub-state; this is the general rationale of this solution; dw: ok df: There is no way to check whether invisible updates are proper; you can only check them if you know the private sub-state; - all target related attributes were renamed to trg prefix; removed the inconsistencies: (tgt, trg) - we introduced based on the public review comments the explicit handling of Processing Instructions; agents should process processing instructions in XLIFF documents; in the last meeting we agreed that we cannot possibly specify anything else as processing instruction is a core feature of XML; - concerns have been captured and included in the spec as warnings, there is also a PR: you must not use PIs to compete with core/module features; we can ask agents to preserve PI; but there is no guarantee they will survive specially in lower structural level elements; this is is expressed in the warnings b: I support this; df: I was doing the normative language .. using agents related terminology and I was doing the constraints; - <conformance section> - section has been divided and numbered: *document conformance *application conformance and *backward compatibility - introduced processes and agents related terminology; they are used throughout the doc, still WIP; a: Needs a consistency check throughout the spec in relation to process and agent related terminology df: Sure, I am working on it b: That's clear; I like the numbered conformance statements and the new definitions;
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:20130812T000000Z
DTSTART;VALUE=DATE-TIME;TZID=America/New_York:20130806T110000
DTEND;VALUE=DATE-TIME;TZID=America/New_York:20130806T120000
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, 16 July 2013
https://lists.oasis-open.org/archives/xliff/201307/msg00086.html\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. Readiness for second public review ballot?\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=35927
UID:https://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=35927
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]