Dear all,
Please find below a summary of today s discussion.
Attendance: Rodolfo, LucÃa , David,
Yoshito, Bryan.
Regrets: Manuel .
I. Administration
R: I move to approve 3 rd
May meeting minutes.
https://lists.oasis-open.org/archives/xliff/202205/msg00001.html L: I second.
R: Meeting minutes approved.
II. Technical work
A. ISO template.
https://github.com/oasis-tcs/xliff-xliff-22/issues/3 David.
I did not have time to work on this.
B. Requirements for < sc> and <ec>.
See the original question
https://lists.oasis-open.org/archives/xliff/202204/msg00023.html ,
the discussion with Rodolfo on the mailing list
https://lists.oasis-open.org/archives/xliff/202204/msg00025.html and the discussion on the last meeting (point B)
https://lists.oasis-open.org/archives/xliff/202205/msg00001.html Y: I have just created an issue for this one (15).
R: It is quite
clear, we need to decide what to do with it.
Df : There is a copy-paste error. the
attribute isolated , it might be elsewhere in the issue.
R: it is not a big issue.
Y: I need to add the code with the brackets.
R: You can use the preview option to see if the code is properly displayed.
Df : what is in target is driven by
rules, you need to check if the corresponding attributes are in the source. This is related to the state attribute.
R: the first segment is translated.
Df : I see. The problem is that sc should
be marked as isolated.
Y: I wanted to make this example valid. At this moment, depending on how to read the specification, you need to add the isolated= yes . During a translation
process, sometimes you do not have the target.
R: Clearly this sentence is right. What I am not happy with the sentence that only applies to <source>, but it can apply to target if the state value is
not initial.
Df : I agree with it. It is kind of
tricky.
R: If you add that text, I can adapt to the specification.
C. Use of
fs:fs/fs:subFs in <note> element. Yoshito. See the original question:
https://lists.oasis-open.org/archives/xliff/202204/msg00004.html and the discussion on the last meeting (point C)
https://lists.oasis-open.org/archives/xliff/202205/msg00001.html R:
Bryan, I do not know if you have seen Yoshito s discussion on this topic.
B: I am still having issues not receiving the messages from the mailing list.
R: you cannot add fs in note.
Df : you can format it as <a> and then
format it.
B: The issue is with the use of fs in note.
Df : I think it is perfectly fine.
B: we have a processing requirement that does not allow us to scape elements. It is designed to do something but then we discourage it.
Y: note element is fs allowed. I understand David s points. I feel that it is
awkward, not wrong.
Df : note is xliff commenting method,
it is meant for human readable messages. It does not have the same formatting capabilities. So of course, fs is limited. But you can look at the html elements are allowed, it is a hint for styling, it is not an interoperability thing. I do not think any change
is needed.
R: I do not want to add inline elements to notes, it would be a mess.
B: we should just allow the fs.
Df : fs is a preview mechanism. It is
ok to style the note. At least to give a hint. It is limited but it is intended so.
B: I think the use of fs without fs, is not the goal of that module.
Df : you can still use an element that
allows for formatting and helps to style the preview.
Y: my impression is that when I look at this, this functionality is very limited. It might not be a part of the spec, but an example of a use case.
Df : I think we all agree that we do
not want to allow inline in the note element. I would suggest we can add a note in the fs module to express.
Y: more
importantly, I would include a use case.
Df : yes, you can group notes.
R: Do you know any tool that currently supports fs?
Df : I think Trados is using fs as a
request of the EC.
R: It partially supports 2.0. It does not support matches nor notes.
Df : their internal format is still
xliff 1.2, they use 2.0 for interoperability. I can volunteer to write the note warning. But I would not have time to create an example.
R: This is not
critical, it is a limitation.
Df : Exactly, I am suggesting to add
a note in the fs module.
R: I would put it in the note element.
Df : for me the natural place is the
fs module, but it can be also close to the constrains in notes.
R: I do not think we need to do anything here.
Df : you can add a sibling note.
Y: I think that explanation can go to the fs module.
R: I think it can be also in the note, it might be logic to have it in here.
D . Processing requirements for state
attribute. Yoshito. See the original question:
https://lists.oasis-open.org/archives/xliff/202204/msg00006.html ,
the discussion with Rodolfo on the mailing list
https://lists.oasis-open.org/archives/xliff/202204/maillist.html and the discussion on the last meeting (point D)
https://lists.oasis-open.org/archives/xliff/202205/msg00001.html Issue 14 in
Github.
https://github.com/oasis-tcs/xliff-xliff-22/issues/14 Yoshito
R:
Yoshito, I also created an issue for the state attribute that we discussed last meeting. I have modified the text according to what was discussed
last meeting.
Df : The must should be in the style.
We used the style for that. The other part is using caps. You should use capitalised can too and use MAY instead. The stylesheet needs to say that this needs to be capitalised.
R: in the new official stylesheet,
glossterm is no longer capitalised.
Df : this is the way that machine can
identified.
R: Yes, the stylesheet does not change them to uppercase, we need to change them in the source. I will search and replace all
glossterm elements and capitalise.
Df : I believe the changes you made
is equivalent. It is very important that the glossterm are capitalised.
R: If you are happy with this change, we can leave it as it is.
R: With that change, then
Yoshito s example is valid.
Df : I would like to keep the right
to sleep on it, but it looks like the same the logic is maintained. Do you keep the change log?
R: I have started modifying the log change today.
Df : For this one, it is important to
record that is only a clarification, that is not really a change in the meaning of the spec.
R: I do not know how to make the difference between the core and the extended version.
Df : Can you look for BCP 14?
R: (goes to Key words ) It is not there.
Df : Good, you need to change the existing
reference to BCP 14 .
https://tools.ietf.org/search/bcp14#:~:text=BCP%2014%20-%20Key%20words%20for,use%20in%20RFCs%20to%20Indicate%20Requirement%20Levels R: Can you open an issue to change that?
Df : I can do it yes.
R: it is not a big change, it does not change the way we use xliff, it only changes the way we write the spec.
E. Clarify validation of core elements in modules (Issue 9).
https://github.com/oasis-tcs/xliff-xliff-22/issues/9 David.
Df : they are part of the module, I
understand.
R: there is a problem if you want to
use startRef (Rofolfo shows dataRef and match in the spec 2.1). We have the original data in <match>, when we want to point to dataRef, the definition of dataRef does not point the match, only the unit.
Df : we need to clarify it in the module.
I am not sure is a problem. It just needs a better description on the spec.
R: the bad news is that the implementation of Trados does not like it. It creates interoperability issues.
Df : It is their problem.
R : It is also my problem, because
my files are not well supported in their tool.
R: I can write the
dataRef clarification.
F. Version attribute. See meeting minutes from February meeting.
https://lists.oasis-open.org/archives/xliff/202202/msg00004.html .
Rodolfo
R: Last time we talked
about having the enumeration and accept the following values 2.0, 2.1, 2.2.
Df : I remember the discussion we had.
I am split between the enumeration and the pattern.
R: The problem with the pattern is that 2.3 would be valid.
Df : that is the idea.
R: But when we will create 2.3, we could add the enumeration.
Df : For the long term, it might need
less maintenance.
R: I am thinking about the
validation code. It is easier if you have the enumeration. XML parsers do not like the pattern, but they are happy with enumeration.
L: For historically reasons, we used to have enumeration in 1 .2
and that did not cause any issues.
R: You are right, it did not.
R: any objections?
Df : I do not object.
R: Ok, so I can make the change.
G. Namespace name. See meeting minutes from January s meeting.
https://lists.oasis-open.org/archives/xliff/202201/msg00001.html and February meeting
https://lists.oasis-open.org/archives/xliff/202202/msg00004.html H. Test suite correction.
Schematron (update).
https://docs.google.com/spreadsheets/d/1uaQ1oSqhXRkRKXNLvgIwcffvNzhcTj9dIkIN__7EH4o/edit Df : I do not have much time, I might
try to recruit somebody to this task
I. New feature requirements?
III. Subcommittee and sister TC reports
B. XOMOS - Sister TC
Df : I could not attend last meeting.
They are doing some steady work.
L: Meeting adjourned.