[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting minutes
|
Dear all, Please find below a summary of today’s discussion.
Attendance: Yoshito, Rodolfo, Lucía.
Regrets: Bryan.
I. Administration
R: I move to approve the meetings minutes
L: I second. No objections, meetings minutes approved.
R: I do not think it is a requirement to have the prefix, I was just quoting is what is currently said in the spec. (Rodolfo shares the wiki page)
Y: I am still confused if those prefixes are the same as the ones used.
R: This is something different.
Y: If I want to have the subtype, what do I need?
R: you need the schema that contains the correct values, you need to have the prefix registered.
Y: If this is only used for a custom value.
R: How do you interpret this question (R. refers to the first question in the FAQ).? For me the prefix and the subtype could be the ones that you have in the custom namespace. You can
validate on your side, because you have the schema. When we started designing 2.0, we were having an issue with custom namespaces from one company. Other tools were unable to work with those customised markup. XLIFF 2.0 was not going to allow custom. That
is why we decided to have modules. IBM and Microsoft pushed to have customed namespaces. The compromise was that you had register the customs. I left the TC because I opposed to have customed namespaces. I do not know why this requirement was introduced. In
one side it says that you can use and in another way that you don’t. We need to fix the contradiction, in any case that will mean that we need to change the core. I would suggest to remove the requirement to register your prefix.
Y: you have pros and cons, the pros is that you make it more usable for implementers. The downside as you said is that it might not be understood by others.
R: Do we need people implementing it? We can change the requirements. Validators can ignore this. If you put a custom subtype, you cannot complain.
Y: If you register the sybtype in prefix, it might be very abstract.
R: That is why I said, that the validators should ignore it.
Y: The actual processor implementing should understand the semantics.
R: IF you define your own semantics, the validators should ignore. That is a problem between you and the translator. We need to put an official list of subtype semantics.
Y: In many cases, substate allows you to define the process.
R: We need to change this requirement, it needs to be open. If you see the excuse in the FAQ, they talk about fragment identifiers, they do not talk about values. This needs to be changed.
R: It is userdefined, why to do you need a prefix in this case? You have a good case. Do you need a prefix?
Y: I do not.
L: This adds to the argument to changing the core. In the previous version of XLIFF the problem with state is that it had 12 predefined values, I worked with this with Friedel Wolff
on this issue, main developer of Virtaal, and the problem is that some implementers might not be able to include all those state values in their tool, they might not need all of them. The rationale of simplifying the state predefined values was that, and the
idea is that the subState can be used to include predefined values that implementers might used.
Y: How many states really depend on use cases. Some user case only need 4 states. But others more or less.
R: These 4 states that we have can be subdivided in several ones depending on the user case. That is why subState should be user defined. The core should not require to register this,
but to leave it open.
Y: At this moment nobody can validly use a substate.
R: Indeed.
Y: subtype might be the same case.
R: Yes, indeed. We need to fix this as well. The problem is that if you want to validate and you use namespace, the prefix in the value of the attribute not in the name.
R: xml:namespaces do not apply to the value of the attributes.
R: if it is user-defined, you can put whatever you want.
L: I totally agree with it. Your solution simplifies the implementation, the only downside is that it modifies the core. But this adds to the argument that the core needs to be modified
if we want the implementers to use it.
R: We should have a roll call on this.
L: I will add this to the next meeting agenda and we can have a roll call on this.
Y: I will add the issue to github.
L: Thank you, Yoshito, I will add that point in the agenda so it will be easier for others to get familiar with the discussion before the meeting.
B. Open issues in Github (xliff 2.2):
https://github.com/oasis-tcs/xliff-xliff-22/issues
Can we close them? Action items? (we will have a roll call on the issue #4 in github on the 19th of October, official meeting)
R: (Rodolfo goes over the rest of the issues)The other issues will be tackle when we will modify the spec once we discuss the 4 issue.
L: Ok, thank you.
C. Migration guide & Online Validation Tool. Feedback, next steps.
https://lists.oasis-open.org/archives/xliff/202101/msg00002.html
Migration guide, I do not know if it makes sense to make it now if we are going to modify the spec. L: Meeting adjourned. Lucía |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]