< Return to Calendar

* XLIFF TC Call (Conference Call)
Name * XLIFF TC Call (Conference Call)
Time Tuesday, 06 August 2013, 11:00am to 12:00pm EDT
(Tuesday, 06 August 2013, 03:00pm to 04:00pm UTC)

Please join my meeting.
Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

   France: +33 (0) 182 880 780
   Germany: +49 (0) 892 2061 159
   Spain: +34 911 23 0850
   Sweden: +46 (0) 852 500 612
   United Kingdom: +44 (0) 203 535 0611
   United States: +1 (773) 945-1031

Access Code: 905-529-225
Audio PIN: Shown after joining the meeting
Meeting ID: 905-529-225


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;



I Administration (0:00 - 0:10)
  A. Roll call
  B. Approve previous meeting minutes, 16 July 2013 https://lists.oasis-open.org/archives/xliff/201307/msg00086.html

II XLIFF 2.0 (0:10 - 0:45)
  A. Actions required to stay on track according to our timeline https://lists.oasis-open.org/archives/xliff/201306/msg00042.html
     1. Readiness for second public review ballot?
     2. Reference Implementations for XLIFF 2.0 [identify by 16 July] (Kevin) https://lists.oasis-open.org/archives/xliff/201306/msg00040.html

  B. Public review completed
     1. Comments are tracked on the wiki: review assignments and status
     2. Review progress on comment replies and updates

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 - )

Submitter Bryan Schnabel
GroupOASIS XML Localisation Interchange File Format (XLIFF) TC
Access This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
  • OASIS Open (General Membership)
  • General Public