< Return to Calendar

* XLIFF TC Meeting - public review analysis (Conference Call)
Name * XLIFF TC Meeting - public review analysis (Conference Call)
Time Tuesday, 06 December 2016, 11:00am to 12:00pm EST
(Tuesday, 06 December 2016, 04:00pm to 05:00pm UTC)
Description

Please get the dial in information from our private Action Item here:
https://www.oasis-open.org/apps/org/workgroup/xliff/members/action_item.php?action_item_id=3663

Minutes

Agenda

Review Public Review comments in JIRA

https://issues.oasis-open.org/browse/XLIFF/

Attendance: Felix, David F., Bryan, Soroush, Phil, Yves

 

B: The second review is 15 days.

DF: If we resolve the big issues, we could start the second review before new year.

Voters: Phil, Lucia, Felix, DavidF, Bryan, Soroush, Yves, Tom. We have quorum. Actually all voters are in attendance.

 

B: Approve meeting minutes from last meeting.

https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201611/msg00038.html

Plus addendum from David:

https://___www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201611/msg00041.html 

Df: I second.

B: meeting minutes approved.

 

ITS namespace issue:

(DavidF shows his screen with JIRA).

DF: https://issues.oasis-open.org/browse/XLIFF-9

We did not come to a solution last time. If we allow the W3C ITS namespace as a module namespace, we need to add the namespace to the XLIFF-defined definition. Also we need to be able to use our validation artifacts to validate the module. If this is not resolved we cannot do it IMHO.

F: In Docbook 5.1 that has been recently approved as OS we also have ITS w3c module combined with their namespaces and artifacts. Their schema design is different but the integration can be done. I can take an action into have that integration. Hopefully Soroush can be involved.

DF: I think that Soroush can do it. By using the w3c namespace we will allow genric ITS processors to parse it, but we will keep our validation artifacts.

F: yes, but the schematron will have to declare the W3C ITS namespace.

DF: sure our xsd and sch will change declaration to W3C rather than the OASIS URN, but we will keep our validation structure and logic. Can we do it for both sch and xsd?

F: yes, definitely.

Df: So this is resolved, but also need to extend the “XLIFF-defined” definition by the W3C ITS namespace.

Y: When you look at the spec we define what is XLIFF-defined.

Df: If we make our ITS module based on the W3C ITS namespace, we should add it to the XLIFF-defined namespaces.

Y: You have already a precedent with the XML namespace. It is not listed as XLIFF-defined.

DF: But the XML namespace is not the base of a module.

Y: Resource data module defines what can be done with the namespace. What is the problem the?

DF: We would have a module acting as an extension.

Y: I warned long ago that we should not make a difference between extensions and unsupported modules.

Y: It is also an implementation problem. If you change that, you change the core.

S: If a tool is already using ITS but not in the way XLIFF defined, it cannot use itanymore?

Y: that is a very good question.

DF: This would be actually worse if kept itsm. W3C ITS namespace will act as module where defined and as extension elsewhere. That’s not a concern.

F: I made an XLST experimental implementation, it behaves the same way with itsm or the W3C ITS namespace, the differences for generic ITS processors are solely with the pointers and pseudospans.

Df: The Localization Issue data category is the big use case that can be resolved if we use the W3C namespace. I am naturally opposed to abandoning the OASIS URN based itsm namespace, because it’s a big change late in the game.. But the Localization Quality Issue is the gig use case that makes me look for a solution with the W3C namespace.. As itsm it wouldn’t be accessible for generic ITS processors..

Y: it does have implementation impact. People working on 2.1 will have to add that for verification.

DF: This is a fundamental definition, but it doesn't have XSD impact.

DF: We also have to deprecate the 2.0 ctr namespace.

Y: but this changes the core, it changes the method to see what is XLIFF-defined

Df: In my view, it does not change the method of verification, just its parameters.

Y: But it has code impact.

Df: This is now broader than the ITS namespace discussion. If we are not allowed to change parameters of “XLIFF-defined”, I do not know how we can deprecate module namespaces or add new namespaces.

Df: can we resolve this today?

Y: to me, it is changing the core. It does not seem right for a point release..

DF: We are not changing the core schema or the namespace, so it is good to me.

DF: Other proposals on how to resolve this?

Y: From my point of view, I do not know.

B: I do not have any alternative proposals either.

DF: if I move to accept my proposal, would you vote against it or would you abstain to let it proceed?

Phil: We are making a change of a version that is not yet released, I would vote for it.

DF: Do we make the decision today or should we postpone until new year?

B: If all the ideas are already said, and there is no alternative. I would go on with the vote. There is no point in postponing it.

P: We have some concerns about breaking something that is already there.

Df: I do not know how to do it otherwise. There are really 3 options:

1) extend ITS (people didn’t think this was practical) , 2) stick to itsm OASIS URN namespace and declare that some of the categories are simply not accessible for generic ITS processors, everything can be roundtripped though 3) move towards the W3C namespace and extend the XLIFF-defined definition.

Y: I am not sure if we have to add the ITS namespace to the XLIFF-defined, what implications that will have it to say it’s XLIFF defined? I don’t like changing XLIFF-defined..

DF: But if we cannot change parameters of XLIFF-defined, we cannot deprecate any modules and there will be no way to have the new data model for CTRM.

Y: I understand your concerns, but it is weird that way..

DF: We just change the parameters.

Y: We said that changing the document version would not change the implementation of the core for tools.

DF: We cannot guarantee that, it depends on the specifics of your implementation. If you change now the code so that it works with namespace parameters it will be easier to deprecate or add other namespaces for 2.2.

Y: You cannot change what is XLIFF-defined in 2.0, this is version specific.

DF: Exactly, it says these are not considered XLIFF-defined for the purposes of the XLIFF 2.1 specification. We have no way to affect what was XLIFF-defined on 2.0. If you have a 2.0 processor, the W3C ITS namespace won’t be protected. If you use a 2.1 processor it will be protected.

DF: I move that this is the consensus text to resolve the issue 9:

 

To use the W3C namespace for the ITS module, to keep our validation artifacts (xsd and sch) that will however declare the W3C namespace. We will extend the XLIFF-defined definition with the W3C ITS namespace.

 

P: if we do it, and there is an issue, there is no way back, isn't it?

DF: In the second public review people can comment again. We of course try to do big changes before we go public but sometimes it happens that we have to do big changes as we do now..

DF: Do I have a second for the motion?

B: I second

DF: Is there any dissent?

DF: I hear no dissent. Thanks everyone, especially Felix that this could be resolved today. We will be able to move ahead with this.

 

DF: Issue 4 resolution from last time is now implemented in the latest printed version.

DF: In the last moment, I realized that we cannot track attributes that are on segments. So I guess we’d need to introduce a <segmentItem> to make the state and subState attributes trackable again.

Y: Why cannot track them with item?

DF: you can only track attributes that are on the element that you are tracking (through appliesTo).

We are allowing in this new data model to track units, source and target, but not segments or ignorables. State, for example, is only on segments, tools might want to track that. In fact this is the attribute that makes sense to track..

When you are reviewing, please have this in mind and possible ways how to solve it...

 

DF: I have reported an error after the review officially closed (issue 17). It is a trivial editorial issue in Normative References but very important ones.., it is fixed now in the current proposal. I move that this solution is accepted.

B: I second.

DF: any dissent?

DF: I hear no dissent, so I mark that as Resolved and Applied.

 

DF: we got some good comments on the XLIFF core made by Ján Husarčík from Moravia. There was an issue for the schematron (issue 10), Soroush, have you integrated those changes?

S: I will apply them tomorrow.

AI for Soroush to apply the resolution to Iissue 10 and update the schematron.

DF: All TC members do have access to JIRA and can post comments. The comments are automatically posted to the TC list.

DF: Issue 13 relates to that and goes further..

Y: isn't that changing the core?

DF: It is in a sense, there is a gap in core, the question is how to address that. We can address it with a note or a warning not add anything normative, to formally prevent a core change ...

Y: That means that core processor will have to change their behavior.

DF: In fact Lynx doesn§t apply the harsh interpretation AFAIK

dF: Yves, can you take an AI to have a look at issue how Lynx handles the Issue 10?

Y: Will do..

DF: Jan asks for more clarity on some other connected issues with handling editing hints.

DF: I will close with an appeal to TC members to have a look at comments in JIRA and comment/ propose solutions.

 

Meeting adjourned.



Agenda

We will spend this meeting determining next steps, second committee draft public review, or move to candidate draft?

Public Review ended 25 November.

Review Public Review comments in JIRA

https://issues.oasis-open.org/browse/XLIFF/

 



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