[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: meeting minutes from XLIFF TC meeting on 21st January 2014
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 csprd03
dF: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]