< Return to Calendar

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

Please join my meeting.
https://www1.gotomeeting.com/join/905529225
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
Minutes
Regrets: Lucía, Kevin Attendance: Victor Amaya, Helena Chapman, Tom Comerford, Fredrik Estreen, David Filip, Ryan King, Yves Savourel, Bryan Schnabel, Joachim Schurig, Asanka Wasala
10 members in attendance, 9/14 voters, meeting has quorum
F, R, D, mrk vs. refid, problems w/mrk/note source v target
F cannt find a way to allow ctr and re-segmentation
R: it can be done technically, you can reference segments from unit.
D: That way you would still use stg that would perish with the segment on re-segmentation, there would be no point in moving the modules out of segment if the reference was still to segment, I believe we discussed in the F2F using mrk spans.
F: yes, say you start off with a file where you have four segments from the initial segmentation, and you do version tracking on it; you already have couple of source versions for these four segments; then you merge these four segments into two segments; because you do re-segmentation; for the source part no problem because the markers remains just as they are.. ; but you'd probably need two marked up spans in the target and obviously it’s not a problem just to move the tags down; but how to distribute the new target translated text across these two marked spans in a meaningful way?
R: I don't see much fundamental difference between a solution with a ref attribute and using a marker because in either case the tool that does segmenting needs to know.
F: Segmentation is often done without perfect align of two pieces into different languages; so I don't believe there is an automated way of doing this in a bulletproof way; there are various levels of it; with a certain amount of error frequency; it is also very different depending on what module we are talking about; the notes for example do not exhibit this problem;.so notes can easily move outside and markers have to point in hierarchy whereas something as ctr to make sense you really need to keep the original segmentation so that the changes that happen are actually tracked against the correct piece of original text. I was trying to come up with a solution on how to keep it on the segment level; I cannot see any reasonable solution where re-segmentation would work with ctr on segment level
R: if I have three sentences in my original source and I have an author and date time attribute and a CRC sitting on that source and now I need to break that up into three different segments; I could just recalculate each one of those attributes; I could set the author to same author; same with the datetime; and I have to recalculate the CRC anyway; so not sure about the problem with the segmentation on ctr?
F: if you have a tool that knows nothing about ctr that performs the segmentation; ctr is a module; it is an optional feature; whereas re-segmentation is a core feature; so a tool that performs the re-segmentation should not necessarily have to have any knowledge whatsoever about the ctr module and the hope is that we can have a solution that works without breaking the functionality of the modules
R: for any module?
F: not for notes for example
R: notes is core
F: val rules for example have the same problem; solution there would be to move them to unit level; so the rules apply to unit as a whole instead of segments; and that you could apply also to ctr; so all tools always track on unit. that means that the portion being tracked is constant throughout the lifetime of the document; but I am not sure whether that granularity is acceptable;
R: does that mean any processing agent would have to recombine all segments before it applies val or ctr?;
F: yes
D: I believe you wouldn't need to do it physically in the file, just an equivalence relation could be defined
F: propose to change the ballot text
R: what are the modules beside ctr and val?
F: FS need to change for example, matches module need to be re-worked; matches module is different; there is always a position of source that always relates to a match; and there is no real need to markup where in target the match was inserted
F: slr isn't on the segment, I wanted to avoid this issue
D: there is no issue with FS; it simply won't be there
F: yes, so you remove the FS from segment
R: as far as val and ctr go, I am ok to move those to the unit level as long as we have a PR that says you need to recombine segments before applying ctr or val; this causes problems for CRC attributes added to the ctr; CRC have to be calculated on the entire unit; are you ok with that?
F: ok with that; alternatively if it is a big problem, I could live with not having it if it causes problems for initial version
R: wondering, if it is better to drop it for the time?
F: fine either way
J: I am really against removing CRC although it is not a security or other measure; it does not give you real security from people changing segment; but dropping it would mean no protection against accidental damage
D: you might want to track segment, just be aware that the ctr is bust as soon as resegmentation occurs
J: it only tells there had been some accidents on the file itself; so it makes sense to have it on the unit; for authentication or sort of legal requirements it does not work and that has to happen on segment level
F: suggestion: remove it from the unit itself, so the actual source and target and keep it on the revision tracks because you can always compare the content of the latest revision with the content of the current source or the target and they should be the same unless somebody did a non-tracked change to the source or target
D: sounds good
J: agree
R: so you are saying that an agent would compare the actual source and target and not the crc
F: yes, the crc can stay on the actual version. track notes which will be one for the source content and one for the target content and one for notes content but we should not have a crc on the actual unit itself because since the latest revision should always be the same as the current source or  target; you should always be able to just compare the content itself between the latest revision and the current source or target and see if they are the same; if they are not somebody has made a search-replace operation or some other untracked change and you could for example warn the user that source or the target you are editing has other changes which are not tracked..
R: if you are comparing the content what is the CRC value?
F: protection against somebody running e.g. search and replace on a single word in the entire file with a text editor which would change the recorded revisions together with any occurrences of source and target and then I would know that my revision history is bust
D: agree with F
R: we should make the decision whether we are going to move modules, notes out of the segment to unit and vote on that and then solve the technical details
H: personal opinion: we should not define our own mechanism to secure the content; I don't like having everything living in the document
R: agree; I wouldn't use that CRC attribute; I am not opposed to having it as optional
F: we should allow an extension point/attribute in the ctr, so that tools that want to do this checksum can implement it.
H: it is a good thought: certificate to authenticate the ownership of the content; but I will probably do it external to the actual file;
R: F: shall we drop the CRC in ctr and just allow extension point, which we already do?
F: yes, it is something that I would do as a trade-off to move forward and to get the other functionality completed
D: we are planning to use ref standard for CRC calculation
F: we are talking about storing that information external to the file. so the file itself does not carry its own verification.
D: how about the extension point  wrt interoperability?
F: I have several use cases for the checksum; I can include some formal checksum into my flow.
D: so you don't need the points formally in the spec
F: I’d resolve it; it is not a hard requirement; I am prepared to drop my request feature and just have it as a custom extension
R: checking the revision can be very dependent upon the processing tool; having it externally makes more sense;
F: it’s not a super import requirement for me
R: key is the ability to check the change track outside of an XLIFF aware system as well
B: are we in a position to resolve re-segmentation through roll call ballot? Do we have the quorum?
D: keep the quorum for 10 mins
R: formally propose the roll call ballot
D: second
V asks for clarification
R: unit level or whatever level specified
B: Ryan proposes move modules and notes out of segment
D takes a rollcall ballot
Ballot results: HY, TY, FY, DY, RY, YY, BY, JY, AY
D: Ballot passes unanimously
D: Sean will be joining the TC from LRC, can you stay for 10 more mins?
D: I proposed for the res module to have similar mechanism as skeleton; option to have external or internal files;
R: yes, agree with your proposal; I had a comment about it in the list about the usefulness of the res module
D: I am not opposed to having it in the unit level
R: prefer to have it on unit or file; not sure how the rest of the TC feels about that
H: no opinion on this one
D: is there anyone who has issues re: this? these are modules and optional
F: I don't have an opinion on this either; I prefer binary information not be in the file; having it externally is preferable as it keeps the size of the file down
R: fundamentally I don't think there is much difference to what we are doing with mda anyway
D: do we try to have more discussion here? I wanted ask about order of elements; Sean's proposal to the list; Ryan reacted. It is a workable proposal
R: I don't see a reason for enforcing the order; I am ok with that once we have all the right elements and extension points.
D: Unfortunately we don't have Yves or Sean here; it is for parsing; it is easy to check whether something is there or not 
F: it does not matter much for checking something is there or not; better for streaming;
R: makes sense for source and target which are already defined in a unit; what is the effect if metadata occurs before or after the segment.
F: I’d be fine with core elements having defined order, and then followed by modules, and extension in any sequence
B: +1 for order, especially because of xslt
D: everyone agrees at least the core should preserve order
R: I am not even opposed to having order in modules; it makes sense regarding the XSLT comment
D: order is better for parsing
B: my desire for order is based on the fact that it is difficult sometimes to know which module is associating with which core elements; if there is a stricter consistent way of representing id or idref that will be alleviated; but that will put too much pressure on the module writers; therefore I prefer order
R: what is the purpose of having id and a ref? if modules are expected to live on the unit level ; what would be the actual need for have id and idref?
D: if you want to point to something using a marker
F: solve case where you have a module that references by id potentially different to core element; so you could have something that references both units and groups for example. idref only works if you have an id space across everything that you can reference
R: is the question referencing from a mark element to a module or reference from a module to mark element?
F: module to mark element or unit example; .it is easier for things like XSLT, XPath if you have unified id space for id lookup to get right things;
B: I think an id reference can reference any element that has an id, regardless where it exists; problem is that we don't enforce uniqueness of ids; we don't use the ids data type therefore relying on id or idref is not something in XLIFF 2.0 that I think would recommend as a bullet proof way of processing. in the absence of a good id and idref system, using order can be useful.
R: or do we feel like we should drop out referencing and push it into 2.1
F: I think universal IDREF will be a big problem for especially inline elements;  it would be problematic to allocate the new IDs for cloned inline tags if you have to search the entire document to verify that it is not used by something else; also rules out any streamed processing
R: I did send a proposal to the list about IDREF that was specifically regarding the segmentation issues; I can see how it can also be applied to referencing and markers as well; but I agree with Bryan; better to push this to 2.1
B: I am in favour of IDREF for segmentation, but it’s too ambitious for us to use IDREF across all modules for xliff 2.0
R: decision we made here is to not have an IDREF solution for segmentation module
B: my comment is more generic for all XLIFF 2.0 modules
R: let's discuss in the mailing list
B: do you want a ballot for order?
D: we probably do not need a ballot; pretty much everyone agreed; would it be better to have a ballot?
B: we have two options; ballot or call for dissent (CfD)
D: ballot will be quicker; wording is based on the email proposal, making the order consistent on all levels
R: is part of that proposal having notes on both file and group or would you do that separately?
D: I'd do that separately; ballot based on this proposal http://markmail.org/message/qlxb7fsu7j23hcpx
F: Helena left the meeting
D: we lost quorum; Bryan, can you make it an electronic ballot?
F: Why not CfD?
D: very good, I will call for dissent by the end of this week, it will be quicker than a ballot..
R: not clear on the procedure between when you need to formally call for ballot on a call such as this or when you can propose a feature with a CFD and specific timeline; is there a procedure and can you send that to the list?
B: if we have consensus on an item and feels like it is not a very contentious item we can go for a CfD;
R: then I will send my proposals again as CfD and depending on the reaction to them we might discuss them on our next call
D: sounds good
F: in general if people don't have disagreements then we don't have to go for ballots; that's the ideal situation
D: cancelled the P&L meeting
B: AOB?
V: Helena proposed some AOB on chatbox earlier
9:11 AM, H: I'd like to suggest [..] the reference implementation option discussions on emails. Also, I have another thread about translation candidate/match module [..]
Meeting adjourned


Agenda

I Administration (0:00 - 0:10)
  A. Roll call
  B. Approve previous meeting minutes, 18 June 2013 https://lists.oasis-open.org/archives/xliff/201306/msg00016.html
  C. Completed ballots
     1. Add language to XLIFF 2.0 Specification on Processing Requirements for XML Processing Instructions https://www.oasis-open.org/committees/ballot.php?id=2432
        "Vote yes if you agree that processing instructions SHOULD be preserved in an XLIFF "
        Result: Passed (6-5); 5 comments
     2. Remove Glossary from File https://www.oasis-open.org/committees/ballot.php?id=2438
        "Vote yes if you think the Glossary module should not be available at the file element level."
        Result: Passed (6-1)
     3. comments tracker back - review your actions! (DavidF) https://lists.oasis-open.org/archives/xliff/201306/msg00028.html
        Please look for items marked as DELAYED

II XLIFF 2.0 (0:10 - 0:40)
  A. Actions required to stay on track according to our timeline https://lists.oasis-open.org/archives/xliff/201306/msg00042.html
     1. We need a roll call vote today; Re-segmentation behavior - removing modules and extensions from etc.:
         - Option 1: don’t allow if module or extension (make core depend on non-core)
         - Option 2: throw away (if you don’t understand, throwaway –disrupts modules)
         - Option 3: set flag, (if it is a yes, it is undefined behavior)
         - Option 4: Move meta to unit (lots of changes to spec; can still have flag (or different use)
           Note: Here are the latest in the thread: https://lists.oasis-open.org/archives/xliff/201306/msg00019.html and
                 https://lists.oasis-open.org/archives/xliff/201306/msg00026.html
     2. Order of core, module and extension elements in the general tree (https://lists.oasis-open.org/archives/xliff/201306/msg00037.html)
     3. General approach to properties and sub-properties [needed for comments 021 and 053]
     4. Volunteer to UPPERCASE normative keywords through stylesheet [comment 005] (https://lists.oasis-open.org/archives/xliff/201306/msg00023.html)
     5. 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 (0:40 - 0:50)
     1. Comments are tracked on the wiki: review assignments and status
         https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker
        a. 018, 024, 028, 036, 050 and F2F meeting - Extending the Glossary module (Ryan)
           https://lists.oasis-open.org/archives/xliff/201306/msg00038.html
        b. 028 - Action To Be Taken (Ryan) https://lists.oasis-open.org/archives/xliff/201306/msg00039.html
        c. 007, 008, and 027 - have internal/external option in resource data module (Ryan)
           https://lists.oasis-open.org/archives/xliff/201306/msg00036.html

  C. TC list email relevant to XLIFF 2.0, but not to the Public Review
     1. Formalizing the role of extensibility as launch pad for future XLIFF Core or Module features (Bryan)
        https://lists.oasis-open.org/archives/xliff/201305/msg00022.html

III XLIFF 2.X? 3.0? (0:50 - 0:55)
    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: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