 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) |
| Description |
Please join my meeting.
France: +33 (0) 182 880 780
|
| 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;
|
| 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 - ) |
| Submitter | Bryan Schnabel |
| Group | OASIS XML Localisation Interchange File Format (XLIFF) TC |
| Access | This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
|