[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] meeting minutes from XLIFF TC meeting on 21st January 2014
I second David’s motion to approve the meeting minutes of record.
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Monday, January 27, 2014 03:29 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] meeting minutes from XLIFF TC meeting on 21st January 2014
Hi all,
I did not manage to fit these minutes into the kavi text field, so please find them pasted in the body of this message. Great thanks to Asanka for scribing.
Please note that we need these minutes approved as the meeting minutes of record for our progression to csd03 and csprd03.
Therefore, I hereby move to make these the meeting minutes of record unless material objections are notified on this list by Wednesday 29th January 23:59 PST. I am looking for a second.
[start of the minutes]
dF: There are three issues with the spec, I think they are resolvable in the meeting time.
B: Paste the issues into the chat window, so we can focus on them.
dF: We have quorum. I will do the attendance in background.
B: Approval of previous meeting minutes: Fredrik seconds, no objections.
- We still have an active call for volunteers to supplement Lucia, Peter & Asanka as the meeting minute takers; Please contact dF or B if you are interested in taking notes;
- Next agenda item: 1.D
- dF updated the OASIS citation format.
dF: - Confirming attendees: Victor Amaya, Helena Chapman (dropped early), Shirley Cody, Tom Comerford, Fredrik Estreen, DavidF Filip, Lucía Morado, Yves Savourel (arrived later), Bryan Schnabel, Joachim Schurig, Uwe Stahlschmidt, DavidW Walters, Asanka Wasala, Ray Kearney, [14 out of 16 current voters]
- Ray is the new voter;
B: Moving to agenda item 2; dF has pasted a summary of the items we have to focus in this meeting:
dF(via Chat):
- print out ready for csd03/csprd03 vote except for the following:
-(non-normative) schema listings and trees need update
-(potentially normative) comment #130
-(potentially normative) PR on not reordering units
dF: If we agree on exact solutions/wordings in the meeting time, we can have the ballot; If the changes are more difficult then we would need to do an electronic approval.
B: Schema listings and the tree examples in the specification need to be updated. Tom is this something that you can sign up for?
T: Absolutely.
dF: Normative artifacts are up to date; so this shouldn't be an issue.
B: Moving to comment #130;
dF: This is about the candidate annotation in core: After London we decided not to have any metadata on segment to allow for re-segmentation. We had to do reshuffle to strengthen referencing, we added candidates referencing facility; I believe it is analogical with the term annotation facility; you can either use or not use the mtc or gls module; for people who don't use them I believe it is good to have annotation in core. Y thinks that the terms annotation is ok for core; he thinks that marking something as having a candidate is not good enough for core; it should be a custom annotation altogether or it should be moved to the candidates description; I don't think candidate description will be a good place for it. The core device we currently have and that Y wants to remove .has a different function; this allows you to mark a match even if you are NOT using the mtc module and point to your TM server or so; you can have a URI pointing from the core to e.g. an MT service; it can produce a tm match or MT candidate on the fly.
F: I agree with the point that Y has here; just marking something as having a match is not really useful on its own; custom annotation does not tell you anything useful unless you know how to process it further, whereas a term annotation is something that actually provides useful information;
dF: There was this discussion on "what is the value of the ref of the term annotation?" Both of them have vague semantics
F: I agree that the term annotation is useful and the gls module can specify how the ref should be interpreted in the gls module; matches module should justify how its custom markers work.
dF: Referencing is potentially 1-to-many relation; it would lead to amassing markers on the core content if you wanted to point from core to modules; that's why we have now refs on gls and mtc modules; they are not dependent on having this annotation in core; they can point to any identifiable span in the core content; it is useful to mark something as a term, but we also wanted to have this in the ITS module; in ITS there is this term category; term works as a flag; you can mark something as term and also you can mark something as not a term and this is useful in managing terminology. Options are: keep both annotations as is in core; move the candidate annotation to the module, or kill it altogether because you can use custom annotations. If we kill the candidate annotation in core I think we should also kill the ref in the term annotation; semantics of the ref would be vague in the same way as in the candidates annotation.
B: The only comment on this thread has been between dF and Y
dF: Now F more or less agrees that the candidates annotation is not useful itself without the ref.
F: As to the ref into the gls module, I don't really have an opinion on that;
dF: It shouldn't be ref to the gls module, gls module should point with its own ref to the core; in both cases ref in the core annotation is preferably for pointing to external resources not to the modules.
F: I have not looked at how the gls module references into the segments; I would imagine that you have fewer terms than occurrences of terms; which means you might have a quite long list of references to common terms into the document.
dF: The XLIFF glossary is supposed to work as a local collection, to be on the unit; to be just the specific local information; so you think that one glossary definition should be able to point to more than one span in the same unit?
F: Yes; it is very plausible that one term may occur several times in the same paragraph;
dF: Do you think that both are needed?
F: Ideally there should be one way to point; either you could point from markers to the terminology or point from terminology to markers;
dF: Currently both mechanisms are one to one; because you can have multiple glossary entries, you can make it many to 1 from gls to core.
F: But you cannot have one glossary entry pointing to many occurrences.
dF: That would require changing the type of the ref, which is currently URI
F: It would need to be a list
dF: Yes, that's kind of another issue. It seems to me that we probably want to remove the candidate annotation; the question now is if we want to remove the ref from the core term annotation.
F: So if we leave the current ref on the core term annotation, we can point from multiple occurrences within the unit to the same entry, if this was not possible, we would need to make changes to the glossary module to support that use-case. I think we should keep it as a way to achieve that with the least impact to spec;
dF: So you would think that one gls definition would point to one place in the unit and the unit could use the core ref to point to the same definition from multiple occurrences.
F: It is not ideal; but without making more expensive changes we can’t remove the core ref.
dF: That would be a viable solution for me; the term annotation part would be resolved without any normative changes; it would eventually be a note that can be added at any point; pending issue is what to do with the candidate annotation?
F: I haven't looked at it in enough detail; I tend to trust Y on this if he says that it is not necessary
dF: These are actually the different use cases; you might want to reference a TM server even if you don't use the mtc module;
F: If you do, you would use the custom annotation; with your custom annotation specification interpretation of the ref value;
dF: That means it can be killed without compensation?
B: Y joined. request dF to summarize discussion so far.
dF: We just concluded discussing mostly with F what to do about your comment #130 - basically what we agreed so far: we probably would do no action on term annotations; we would probably kill the candidate annotation without even moving it to mtc module because mtc uses different mechanism. You proposed to move it to matches as mtc:match?
Y: Just tentatively. If it is not needed, that's fine.
dF: It's a different use case.
Y: ok
dF: I don't feel strongly about having defined an mtc: annotation, it could be used eventually if there were no suitable marked spans in the core and the Enricher should be able to insert its match even if there was no span available. If the annotation had a ref, it would be in conflict with the mtc:ref.
B: We have consensus, I haven't heard any objections.. the proposal is to remove candidates annotation from core and modify the core ref values.
F: It could be a non-normative recommendation in the matches module: if there is no suitable span you create a new one with the type mtc:match.
dF: The only reason to have it normative would be to preserve the mtc: prefix;
F: Just a quick explanation for Y, the reason why we keep the ref on the term annotation is that we don't have any functionality in the current gls module that allows one term to point to more occurrence within the unit, so now multiple term annotations can point to the same gls entry.
Y: ok.
dF: I started typing the resolutions:
- remove translation candidates annotation from core
- introduce mtc:match annotation in mtc module
F, do you want a note for the term referencing? It is non-normative.
F: I don't care;
dF: if we want to add a note explaining that the core device can be used for the many to many?
F: That would be fine.
dF: I am of the same opinion, with the above two lines, we can take it as a resolution ballot; should we have a separate roll call on it or make it part of the language of the csd?
B: It would be appropriate to have a roll call ballot.
dF proposes. F seconds.
dF: YES/NO Ballot is to:
1) Remove translation candidates annotation from core
2) Introduce mtc:match annotation in mtc module
- Results: unanimous, 14 yes votes, motion carries;
- We can progress on the PR on not reordering units: After we implemented the solution for the sub-flows, Yves said that we are saying that units must not be reordered and that it is a general PR not specific to sub-flows. But then we would need to say you must not reorder groups, files etc.; i.e. we would need to add many such PRs; there was a discussion around sub-flows that this needs to be stressed; but it is understood that the static structure of the XLIFF Document must not be changed; this was discussed also in connection with the ID uniqueness scopes. F and dF agreed if people do something with the static structure, they should undo it before they return or send the file further. I am not sure that we should add a general PR saying that units must not be reordered. That could just be misinterpreted in the way that other things of that sort can be done. Maybe we should add a general PR saying that static structure of the XLIFF document must not be changed; but it is not a part of the described allowed transformations; so why add?
F: I did like the old wording better;
dF: New wording is specifically for the sub-flows case, not meant as a general; it would be very high-level;
Y: there are 2 different issues: we had a constraint for the sub flows, that has been reworded differently; previous wording was better; do we need something globally instead of in sub-flows section? For me, if we don't have something globally that's fine; I think currently the wording of the constraint on the sub-flow is wrong.
F: I agree; it assumes the knowledge that you might not have.
dF: I agree but it is not the issue; I suggested that it shouldn't be there because it should be understood that the static structure must not be changed. But B said let's be clear about that and wanted to have the PR, I just rewrote it inline with the used Agent terminology. A good solution would be to have a non-normative note.
dF: I am proposing to convert it to a note, anyway non-normative.
F: ok
B: That satisfies my initial concern.
dF: We can say something like applications are expected to preserve the unit order as it is due to general XLIFF principle not to change the static structure of the document. F said something like that was in the in-line specification?
F: I would put the parenthesis and name the elements (file, group, unit)
dF: There would be listing these elements, if we cannot find reference.
- (via Chat):
- Applications are expected to preserve the unit order as it is a general XLIFF principle not to change the static structure (file, group, unit) of the document.
B: Looks good to me.
dF: We won't have the PR that would be normative. It would be replaced by an informative note something like the above.
B: There could be a substantive change?
dF: If we later improve the wording of the note, then it won't be a substantive change any longer.
Y: It is not substantive because csprd02 didn't have that PR;
dF: These are different issues. It is substantive in the context of if we can vote on the csd03/csprd03 today,
It is not substantive as a change between csdpr02 and csd03; if we can vote today on csd03/csprd03 with a well-defined set of changes compared to what is published today;
Unless there are other clarifications, I would move to replace the unit reordering PR with the posted note.
B: Any comments before we have an official second?. Bryan seconds.
dF: YES votes: Victor Amaya, Shirley Cody, Tom Comerford, Fredrik Estreen, DavidF Filip, Lucía Morado, Bryan Schnabel, Joachim Schurig, Uwe Stahlschmidt, DavidW Walters, Asanka Wasala, Ray Kearney,
NO votes: N/A
Abstain: Yves Savourel
12 yes votes, (Helena had to leave early) motion carries.
B: Will combine sub-committee reports with call for new business. We continue with XLIFF 2.0; do we need to decide between options 1), 2) and 3) for fragid that Yves outlined on the mailing list?
dF: I forgot to list it in the log. Currently, option 1) is implemented in the specification; there is a warning saying you won't be able to identify fragments using third party namespaces within modules or extensions; I would prefer 3), B would prefer 1); Yves would prefer 2).. Everyone seemed to be able to live with 1). 2) and 3) could eventually have unforeseen consequences; I thought 1) is the least difficult way to move forward; 1) is a clear cut, I believe it eventually can be expanded to 3) in XLIFF 2.1 version; 2) is an ad-hoc solution that would block further development;
B: Main commentators in this thread have been B, dF, Y, other thoughts in the TC?
You [dF] are proposing just keep 1?
dF: The only change was adding the warning. It is NOT changing the mechanism; it is just adding this non-normative warning and it is already in the specification; if we are going to vote on sending the specification to the csd03 and csprd03 phases, we don't need a separate ballot on that. If someone wanted 2) or 3), and if we agreed to have 2) or 3) then it would require major substantive changes to the specification as it is now;
B: Y, do you have any strong feelings about leaving it as 1)?
Y: No. just saw a typo in the warning; not sure why we mention metadata; it could be any module;
dF: Warning is non-normative, and it is just an example; currently this only affects core and metadata; so metadata was chosen as an example;
Y: - There is another typo..
dF: That wouldn't affect the validity of the draft;
B: We've 2 objectives for the remaining time of the meeting: 1) we need to come to agreement on keeping option 1) as outlined by Yves. This is non-controversial; 2) have enough time to vote in favor of passing committee specification draft 03 and public review draft 03 and the other ballot is that TC would vote for B to ask our OASIS admin to arrange for public review.
dF: We can do everything in one vote;
B: We are proposing here to accept committee specification draft 03 / public review draft 03 as we outlined; call for B to ask OASIS admin to conduct public review 03, in one ballot.
- dF seconds.
B: Is it clear for everyone?
V: not clear about the proposal;
B (via Chat):
- I propose to pass the current draft that David posted today along with today's 2 ballots as csd03, and formally request TC Chair to ask OASIS Admin to conduct csprd03dF: seconded, It is a YES/NO ballot, we need majority of ALL voters (not just present).
dF:
- YES votes: Victor Amaya, Shirley Cody, Tom Comerford, Fredrik Estreen, DavidF Filip, Lucía Morado, Yves Savourel, Bryan Schnabel, Joachim Schurig, Uwe Stahlschmidt, DavidW Walters, Asanka Wasala, Ray Kearney,
- NO votes: N/A
- Abstain: N/A (Helena had to leave early)
- 13 yes votes [13 out of 16 current voters], the motion carries, we will initiate the public review with the OASIS admin.
B: It was a unanimous vote among the present voters. This is a strong message! This spec has been the best vetted ever. Thanks for the hard work!
- Moving to agenda item 2: do you want to announce subcommittee meeting?
dF: SC meeting will take place; it will be about CFP for the next XLIFF Symposium in Dublin, June 3-4, 2014, f-2-f preliminary planned for 5th June, as June 2 is public holiday in Ireland.
B: No new business. The meeting is adjourned.
[end of the minutes]
Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]