OASIS XML Localisation Interchange File Format (XLIFF) TC

Hello all,   Following up on our discussion during yesterday’s meeting, we have three possible solutions for the Unique Particle Attribution condition for XLIFF documents that are meant to conform to the schema. The purpose of this email is to elicit discussion of the different approaches, toward building consensus around one solution.   Previous threads relevant to this issue: https://lists.oasis-open.org/archives/xliff-comment/201310/msg00025.html (this became CSPRD02 comment 138) https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201311/msg00052.html   More background on Unique Particle Attribution: http://www.w3.org/wiki/UniqueParticleAttribution .     The three solutions we’ve identified (so far) are:          (1) Remove the explicit references to modules.   The rationale for this approach is that the modules are allowed via the wild-card; hence the explicit reference to a module is not needed. Removing the explicit references therefore resolves the potential ambiguity.   This solution is currently implemented in the schema because the UPA error condition was interfering with development. This was a pragmatic solution to the immediate problem, not intended to suggest this is the only way to address the issue. So the schema currently differs syntactically from the specification, although it neither allows nor prohibits anything differently from the spec.   One key limitation of this solution is that the order of module elements within the wild-card token cannot be enforced through the schema. The specification would need modification to describe the preferred order of module elements, or to define constraints.          (2) Rearrange elements so that at least one required element occurs between the module elements and the wild-card.   Any required element between the module elements and the wild-card resolves the ambiguity. The schema token for a module element in an XLIFF document can be determined unambiguously based on whether it occurs before or after the required element.   <unit>: The only required token is the <segment> or <ignorable> choice. This would be moved to precede the wild-card. We may also want to move <notes> and <originalData> to follow the choice group, as they do now.   <group>: The only required token is the <unit> or <group> choice. This would be moved to precede the wild-card. We may also want to move <notes> to follow the choice group, as it does now.   <mtc:match>: Both <source> and <target> are required, and either could be placed between <mda:metadata> and the wild-card. Presumably we'd want to keep these two elements together.   In each case, the optional elements from XLIFF modules would precede core elements, possibly being the first allowed elements in each of the affected contexts.          (3) Define a container element around either module elements or the wild-card.   A container element for either the set of modules or the wild-card would also resolve the ambiguity. The schema token for a module element is determined based on whether it occurs within the container element.   In the case of modules, we would need multiple container types because <unit>, <group>, and <mtc:match> each allow a different set of modules. A container for the wild-card would apply to any point in the model, and so would be simpler.   If we choose this solution, we need suggestions for a name for the container element.     One additional possibility is to rewrite the schemas in RelaxNG. It appears that the existing sequence of module elements and a wild-card can be defined in a way that avoids the UPA issue altogether.   I haven't tried this; I'm not sure how much effort would be involved, nor what other issues we might encounter. But if there's consensus that the solutions proposed above are not acceptable, I can begin work on rewriting the schema.   Thanks,   Tom           Tom Comerford tom@supratext.com +1 856 787 9090   Supratext LLC 43 Michaelson Drive Mount Laurel, NJ 08054   www.supratext.com  

Thanks, Tom, for putting the options so clearly in front of us, as much as I'd think that the Relax NG solution would be theoretically the best one. I think there are other reasons than just time pressure to stick to schema, such as wider industry adoption. So I'd perefer and I think the TC seemed to be inclined to the solution where wildcards are separated from modules by required core elements. I think that you showed well that it is possible when describing the 2) option below, with modules being a single choice group w/o specified order, unlike the fixed order given now. More detail inline below.. Unless people object, I'd like to ask you to regroup elements in spec and schema as per option 2) as specified below, so that this solution is ready in spec and schema for approval by December. 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie        (2) Rearrange elements so that at least one required element occurs between the module elements and the wild-card.   Any required element between the module elements and the wild-card resolves the ambiguity. The schema token for a module element in an XLIFF document can be determined unambiguously based on whether it occurs before or after the required element.   <unit>: The only required token is the <segment> or <ignorable> choice. This would be moved to precede the wild-card. We may also want to move <notes> and <originalData> to follow the choice group, as they do now. I agree move them together, so that they stay in the same relative position.   <group>: The only required token is the <unit> or <group> choice. This would be moved to precede the wild-card. We may also want to move <notes> to follow the choice group, as it does now. I agree move them together, so that they stay in the same relative position     <mtc:match>: Both <source> and <target> are required, and either could be placed between <mda:metadata> and the wild-card. Presumably we'd want to keep these two elements together. I agree move them together, so that they stay in the same relative position     In each case, the optional elements from XLIFF modules would precede core elements, possibly being the first allowed elements in each of the affected contexts.           Tom Comerford tom@supratext.com +1 856 787 9090   Supratext LLC 43 Michaelson Drive Mount Laurel, NJ 08054   www.supratext.com  

Hi Tom, all, Many thanks for layout the options. I went through, trying to think about the pros/cons. === (1) Just have extension points in the core schema, treat modules and extensions the same from that viewpoint. 1-1) bad: You cannot validate where a given module is allowed using the schema (but you can still validate the module's element). Allowed locations have to be defined by PR in the module specification. 1-2) bad but good: Core processors cannot make the distinction between module and extension: which means they have to preserve everything (not so bad). 1-3) good: The core schema can stay the same when we add new modules. Modules can come and go without interfering with the core. It seems to be a major benefit. 1-4) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the core parts at an expected location. 1-5) good: Making an extension a module requires only changing the namespace. === (2) Would put the modules before the required <segment> in <unit> or or <unit>/<group> in <group>, etc. 2-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its namespace changed. 2-2) bad: Using methods like getFirstChild() to access the required core element of <unit> or <group> is no longer possible, you have to skip over zero or more module elements. 2-3) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not so good). === (3) Would add an element. I'll assume we choose to enclose the extensions not the modules. 3-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its namespace changed. 3-2) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not so good). 3-3) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the core parts at an expected location. My conclusion: Solution (1) seems to be the best in my opinion. The only drawback is having to validate the position of modules' element using the same tool that would validate their PRs. My second choice would be solution (3): it has some of the same advantages as (1). Cheers, -yves

Hi Yves, Tom, Fredrik, first of all in the meeting we had recorded consensus that we go for 1) with modules forming a single choice group at each point where they are allowed.. This is also what I asked Tom to implement in the above.. I think everyone clearly sees that there is no ideal solution and we probably will need to decide with a ballot if this dissent is sustained following the consensus reached in the meeting.. Let me comment inline on the pros and cons summed up by Yves.. 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 21, 2013 at 8:23 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi Tom, all, Many thanks for layout the options. I went through, trying to think about the pros/cons. === (1) Just have extension points in the core schema, treat modules and extensions the same from that viewpoint. 1-1) bad: You cannot validate where a given module is allowed using the schema (but you can still validate the module's element). This is a no go in my view  Allowed locations have to be defined by PR in the module specification. 1-2) bad but good: Core processors cannot make the distinction between module and extension: which means they have to preserve everything (not so bad). This is a no go in my view. The TC decided by a ballot that extension cannot and must not be granted the same level of protection as XLIFF defined modules.   1-3) good: The core schema can stay the same when we add new modules. Modules can come and go without interfering with the core. It seems to be a major benefit. I agree that this is a benefit but the cost is too high IMHO  1-4) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the core parts at an expected location. Same as above, I don't think it actually is a separate benefit  1-5) good: Making an extension a module requires only changing the namespace. I agree that this is a benefit but the cost (1-1 and 1-2) is too high IMHO  === (2) Would put the modules before the required <segment> in <unit> or or <unit>/<group> in <group>, etc. 2-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its namespace changed. This seems acceptable, you will clearly see which extensions have graduated to official modules and enjoy full protection, worth the move IMHO  2-2) bad: Using methods like getFirstChild() to access the required core element of <unit> or <group> is no longer possible, you have to skip over zero or more module elements. You are skipping a single choice group of optional elements  2-3) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not so good). The TC agreed that schema should allow to discern between TC sanctioned modules that have absolute protection and wild card extensions that can contain ANYTHING and might need to get nuked for absolutely valid reasons  === (3) Would add an element. I'll assume we choose to enclose the extensions not the modules. 3-1) bad: As Fredrik pointed out last call, now an extension that becomes a module has to move location, in addition to have its namespace changed. This seems acceptable, you will clearly see which extensions have graduated to official modules and enjoy full protection, worth the move IMHO    3-2) good but bad: a core processor can now know which element is a module and which is an extension, and nuke the extensions (not so good). The TC agreed that schema should allow to discern between TC sanctioned modules that have absolute protection and wild card extensions that can contain ANYTHING and might need to get nuked for absolutely valid reasons    3-3) good: It keeps the main structure of a document always the same from 2.x to 2.z versions: optional stuff always goes after the core parts at an expected location. Good, cost not too high.. just ugly  My conclusion: Solution (1) seems to be the best in my opinion. The only drawback is having to validate the position of modules' element using the same tool that would validate their PRs. The drawback constitutes a no go IMHO  My second choice would be solution (3): it has some of the same advantages as (1). Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, (sorry it's a bit long, but you should read it all). > first of all in the meeting we had recorded consensus > that we go for 1) with modules forming a single > choice group at each point where they are allowed.. > > This is also what I asked Tom to implement in the above. I disagree. There was no consensus during the call, just a *possible* consensus and an action item for Tom to lay out the options so people could confirm (or not) that option 2 would be ok. Why ask Tom to list the options if the consensus had been reached? Tom follow-up, you answered and asked if there were any objections: "Unless people object, I'd like to ask you to regroup elements in spec...". My email (posted the same day as yours) was simply answering that. David, I have nothing against trying to get things done as fast as possible; but I have to say that the number and scope of changes we are introducing without much thinking is a bit scary. Now this specific issue: In this specific case: the issue of where modules and extensions go and can be distinguish is at the heart of a major aspect of 2.0: modularity. Option 1 has one major benefit: the core schema can stay the same when we add new modules. But you say that it is too high of a cost. Currently adding modules will require a new version of XLIFF, with all the burden of getting it approved by OASIS. That is one major cost, and in my opinion it dwarfs not being able to validate the location of the modules with the core schema. As we progressed through defining 2.0 it seems more and more clear to me that we truly need to separate the core from the modules. In fact I think they should probably have different versions and even defined in different documents to make things clear. Having a core that does not change and be able to modify modules distinctly from the core and other modules will be a very significant advantage in the long term. It is actually the *main reason* of having modules. By bundling everything into a single version and definition we are completely loosing that advantage: Every time any module is added or modified the specification must be re-approved and all tools will have to adapt. It's time consuming and we will also end up with tools supporting only some versions of XLIFF, and documents 2.z unable to go through multi-tools processes because of some module that none of the tools are using has changed. David: your main problem seems to have a requirement that module must be preserved while extension may not. Then maybe we can work around this by changing the PR to have the tools distinguish between the two by looking at the *start* of the namespace URI of the extension/module elements. This would allow both kinds to be mixed and keep the requirement intact. I understand the wish for speed. But it should not lead to a bad specification. Regards and Happy Thanksgiving. -yves

Thanks, Yves,  I was kind of surprised when Tom listed all the options again after the meeting where we had decided to go for 2) Nevertheless, my bad, I should not have asked for dissent again, after I had outlined in response to Tom that 2) was the solution we agreed on in the meeting, I should have recalled the meeting consensus, but unfortunately the minutes had not yet been published at the point.. Nevertheless, as I see it, the dissent stands and this will need to be resolved by a ballot in the next meeting. Now to react to your arguments: Adding any module will require a full OASIS process. It is totally independent of this schema issue solution. Any module that won't be approved by the full OASIS process will not have the status of an official module. The change to schema that will be required in case we go for 2, is add a new member (eventually to delete a member) in the single choice group at all three levels where the modules are allowed.This will have no impact on how the core works, except that there will be a different set of modules allowed in these choice groups. The distinction between XLIFF 2.x and 2.y will always be how many module namespaces are allowed and hence absolutely protected in these choice groups, the working of the core will not change unless issues are identified that need to be fixed for the next version.. Finally, IMHO the TC will have failed if we do not kick off the 3rd public review before Xmas Yes, I am trying to drive important changes to resolve technical issues, but at the same time stick to the business decisions that the TC resolved in the course of the standards development. @Tom can you please prepare a spec version that implements option 2 for a live ballot in the next meeting? In case the solution 2 will be rejected by the ballot, we won't be able to progress to csprd03.. and will need to discuss, find and implement another solution.. Cheers and Happy Thanksgiving.. dF   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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Thu, Nov 28, 2013 at 3:40 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, (sorry it's a bit long, but you should read it all). > first of all in the meeting we had recorded consensus > that we go for 1) with modules forming a single > choice group at each point where they are allowed.. > > This is also what I asked Tom to implement in the above. I disagree. There was no consensus during the call, just a *possible* consensus and an action item for Tom to lay out the options so people could confirm (or not) that option 2 would be ok. Why ask Tom to list the options if the consensus had been reached? Tom follow-up, you answered and asked if there were any objections: "Unless people object, I'd like to ask you to regroup elements in spec...". My email (posted the same day as yours) was simply answering that. David, I have nothing against trying to get things done as fast as possible; but I have to say that the number and scope of changes we are introducing without much thinking is a bit scary. Now this specific issue: In this specific case: the issue of where modules and extensions go and can be distinguish is at the heart of a major aspect of 2.0: modularity. Option 1 has one major benefit: the core schema can stay the same when we add new modules. But you say that it is too high of a cost. Currently adding modules will require a new version of XLIFF, with all the burden of getting it approved by OASIS. That is one major cost, and in my opinion it dwarfs not being able to validate the location of the modules with the core schema. As we progressed through defining 2.0 it seems more and more clear to me that we truly need to separate the core from the modules. In fact I think they should probably have different versions and even defined in different documents to make things clear. Having a core that does not change and be able to modify modules distinctly from the core and other modules will be a very significant advantage in the long term. It is actually the *main reason* of having modules. By bundling everything into a single version and definition we are completely loosing that advantage: Every time any module is added or modified the specification must be re-approved and all tools will have to adapt. It's time consuming and we will also end up with tools supporting only some versions of XLIFF, and documents 2.z unable to go through multi-tools processes because of some module that none of the tools are using has changed. David: your main problem seems to have a requirement that module must be preserved while extension may not. Then maybe we can work around this by changing the PR to have the tools distinguish between the two by looking at the *start* of the namespace URI of the extension/module elements. This would allow both kinds to be mixed and keep the requirement intact. I understand the wish for speed. But it should not lead to a bad specification. Regards and Happy Thanksgiving. -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, > Adding any module will require a full > OASIS process. Obviously it always will. The issue is that currently it'll be a "full OASIS process" of the whole specification, a change of version. It doesn't have to be that way. In fact, it should not be that way. We should not have to go from XLIFF 2.x to 2.y just because a new module has been added, modified or removed. A software doesn't change version each time a new plugin is available. Not having to change the main part of the specification is one of the main reasons to have modules. > The change to schema that will be required in case we go for 2, > is add a new member (eventually to delete a member) in the > single choice group at all three levels where the modules are > allowed. This will have no impact on how the core works, > except that there will be a different set of modules allowed > in these choice groups. Changing the version has a major impact: every single tool has to be updated: they cannot know if a change of version is only for a change in modules or in the core, so they have to assume it's for the core and therefore check their support against the version of the document. And I'm not even talking about the consequences of changing version from the OASIS process view point: that will become an "opportunity" for changing other things in the specification and to comment on the whole specification. Basically we'll be opening a can of worms each time we add/change/remove a module. Modules should be like plugins and stand on their own, not be intertwine with the core. And the version/specification/schema of XLIFF core should change only when the core changes. > It is totally independent of > this schema issue solution. Absolutely not: The solution selected for this issue (where to put modules vs extensions) can lead to different ways to deal with modules change. Solution 1) allows you to keep the core specification and schema unchanged while adding/changing/removing modules. That is true modularity. We can keep the PR distinction between modules and custom extensions being preserved or not by changing the PR to check on the start of the namespace of the non-core elements. That will work without the tools having to know explicitly about the modules. Your other issue has to do with validation. First, you cannot truly validate a module with only the schema (you have PRs too). So whether or not the verification of the location of the module's elements is done by schema or another mean is not really relevant. As for doing the validation. NVDL ( http://www.nvdl.org/ ) seems to exist exactly to do validation of documents using multi-namespaces. It's an ISO standard and it allows the use of XML schemas. I'm no expert on this, but it seems one should be able to create high-level rules defining where modules are allowed and trigger their schema validation. Maybe Jirka would have some ideas on how to do this. > ... but at the same time stick > to the business decisions that the TC resolved > in the course of the standards development. I don't know what "business decisions" means in a Technical Committee. I just know that one of the main requirements the TC decided for 2.0 was modularity, and currently we have something that looks like modularity but is not really that in practice. > Finally, IMHO the TC will have failed if we do not kick > off the 3rd public review before Xmas I don't share that opinion. The goal is the get a good specification. Achieving it for a given date is just gravy. I've never been fan of deadline-driven agenda in this TC because, while we have been lucky to have a few sponsored face-to-face meetings, most of the work required is not funded. Imposing deadlines on busy people who don't get paid to met them simply doesn't work. If someone tells you they are not very happy with the speed of the TC, maybe you can suggest them to put their money where their expectations are and pay for the time such work requires. Regards, -yves

Thanks Yves, inline.. 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Fri, Nov 29, 2013 at 4:00 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, > Adding any module will require a full > OASIS process. Obviously it always will. The issue is that currently it'll be a "full OASIS process" of the whole specification, a change of version. It doesn't have to be that way. In fact, it should not be that way. We should not have to go from XLIFF 2.x to 2.y just because a new module has been added, modified or removed. What would be the status of the module if the version was not changed?  A software doesn't change version each time a new plugin is available. Not having to change the main part of the specification is one of the main reasons to have modules. Standard is not software  > The change to schema that will be required in case we go for 2, > is add a new member (eventually to delete a member) in the > single choice group at all three levels where the modules are > allowed. This will have no impact on how the core works, > except that there will be a different set of modules allowed > in these choice groups. Changing the version has a major impact: every single tool has to be updated: they cannot know if a change of version is only for a change in modules or in the core, so they have to assume it's for the core and therefore check their support against the version of the document. We said that we do not want to touch core unless necessary, and we said we are not going to break core backwards compatibility in 2.x versions. That does not mean e.g. that a widely used feature cannot graduate to core.. This is an example of a business decision that the TC makes, maybe strategic decisions is better than business  And I'm not even talking about the consequences of changing version from the OASIS process view point: that will become an "opportunity" for changing other things in the specification and to comment on the whole specification. Basically we'll be opening a can of worms each time we add/change/remove a module. This is not necessarily bad, if in 10 years time adding a module will require major core changes,it will be a signal that 3.0 is needed..   Modules should be like plugins and stand on their own, not be intertwine with the core. And the version/specification/schema of XLIFF core should change only when the core changes. We say that modules are optional sets of features, we have chosen a schema language that is not very expressive. If we are going for 1 we are rendering the schema useless for validation   > It is totally independent of > this schema issue solution. Absolutely not: The solution selected for this issue (where to put modules vs extensions) can lead to different ways to deal with modules change. Yet it will not change the fact that new modules will require full OASIS process and new minor version of the spec.   Solution 1) allows you to keep the core specification and schema unchanged while adding/changing/removing modules. That is true modularity. And it makes the schema useless in protecting modules in core only applications  We can keep the PR distinction between modules and custom extensions being preserved or not by changing the PR to check on the start of the namespace of the non-core elements. That will work without the tools having to know explicitly about the modules. Your other issue has to do with validation. First, you cannot truly validate a module with only the schema (you have PRs too). So whether or not the verification of the location of the module's elements is done by schema or another mean is not really relevant. We have chosen a schema language that is not very expressive,so we should not try to make it even less usable for validation by going for solutions like 1  As for doing the validation. NVDL ( http://www.nvdl.org/ ) seems to exist exactly to do validation of documents using multi-namespaces. It's an ISO standard and it allows the use of XML schemas. I'm no expert on this, but it seems one should be able to create high-level rules defining where modules are allowed and trigger their schema validation. We could do this, or rewrite the whole schema in RELAX NG,or many other fancy things if we did not care that the standard publication as result slips to 2015..  I do care,I hope that others do..  Maybe Jirka would have some ideas on how to do this. Jirka would sure be able to do this, if he was on this committee.. but even Jirka would not manage to do this still in 2013..  > ... but at the same time stick > to the business decisions that the TC resolved > in the course of the standards development. I don't know what "business decisions" means in a Technical Committee. I just know that one of the main requirements the TC decided for 2.0 was modularity, and currently we have something that looks like modularity but is not really that in practice. > Finally, IMHO the TC will have failed if we do not kick > off the 3rd public review before Xmas I don't share that opinion. The goal is the get a good specification. Achieving it for a given date is just gravy. The community will stop waiting if we return to the drawing boards. You requested to move modules from appendices to the main body (which was done) and now you request to move them to separate documents with separate approval process. That would mean that both public reviews we made so far revealed that the spec is unfit to progress, we would need to go back to wd01 and have another initial 60 days review. I do not share this opinion..    I've never been fan of deadline-driven agenda in this TC because, while we have been lucky to have a few sponsored face-to-face meetings, most of the work required is not funded. Imposing deadlines on busy people who don't get paid to met them simply doesn't work. If someone tells you they are not very happy with the speed of the TC, maybe you can suggest them to put their money where their expectations are and pay for the time such work requires. Regards, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, >> We should not have to go from XLIFF 2.x to 2.y >> just because a new module has been added, modified or removed. > > What would be the status of the module if the version > was not changed?  Only the version of the added/modified module would change, not the version of the core or of the other modules. Currently our single specification defines several namespaces: urn:oasis:names:tc:xliff:document:2.0 (the core) urn:oasis:names:tc:xliff:matches:2.0 urn:oasis:names:tc:xliff:glossary:2.0 ... If something changes just in the Matches module, according to the current system the new version of the specification will have to go to 2.1. Which means the namespace URIs would then be: urn:oasis:names:tc:xliff:document:2.1 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.1 because changing to this only: urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.0 would be completely confusing for a specification labeled 2.1. So, only the Matches module would change but we would have to change all URIs (and therefore all tools). I don't think it make sense and it is certainly not modularity. > We said that we do not want to touch core unless > necessary, and we said we are not going to break > core backwards compatibility in 2.x versions. As shown above you don't need to break backward compatibility or even change a single thing in all modules but one to have the tools incapable of working with the new version, even if the changed module is not even present in the document: You just need to change the version of the specification. > If we are going for 1 we are rendering the schema useless > for validation   I don't have a good answer for validation. But I know going from 2.x to 2.y at each module change is not viable either. >> Solution 1) allows you to keep the core specification and >> schema unchanged while adding/changing/removing modules. >> That is true modularity. > > And it makes the schema useless in protecting modules in > core only applications  If by protecting you mean respecting the PR that says modules MUST be preserved, I think I've addressed that with the suggestion of changing the PR to preserve the elements based on the start of the namespace URI. > ... if we did not care that the standard publication > as result slips to 2015.. > I do care, I hope that others do..  David, it's precisely because I do care about the success of 2.0 that I'm making all those comments. Releasing next month a 2.0 version that is not truly modular will help no-one. I'm sorry those comments come so late and take me so much time to handle, but the alternative of saying nothing would be worst: a bad 2.0 specification. > The community will stop waiting if we return to the drawing boards. In my opinion it's not going back to the drawing board: We just have an issue on how to change the modules without affecting the whole specification. I don't think the community would like it very much when they realize all tools have to be changed each time a module is added, removed or modified. > You requested to move modules from appendices to the main > body (which was done) and now you request to move them to > separate documents with separate approval process. Yes. Tom's description of the options to solve comment #138 made me realize the specification is not ready to deal with new versions and modularity. That new problem has nothing to do with the other change. > That would mean that both public reviews we made so far > revealed that the spec is unfit to progress, we would > need to go back to wd01 and have another initial 60 days review. Why deciding to split the main document would make us go back to wd01 for the core? We would just act to fix an issue: we have a single spec defining 9 namespaces and we would decide to have one spec per module. In my opinion the main issue is to find a solution for validation. Regards, -yves

Thanks Yves, I believe that we are making progress, I will comment below selectively. 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Fri, Nov 29, 2013 at 5:00 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, all, >> We should not have to go from XLIFF 2.x to 2.y >> just because a new module has been added, modified or removed. > > What would be the status of the module if the version > was not changed?  Only the version of the added/modified module would change, not the version of the core or of the other modules. Currently our single specification defines several namespaces: urn:oasis:names:tc:xliff:document:2.0 (the core) urn:oasis:names:tc:xliff:matches:2.0 urn:oasis:names:tc:xliff:glossary:2.0 ... If something changes just in the Matches module, according to the current system the new version of the specification will have to go to 2.1. Which means the namespace URIs would then be: urn:oasis:names:tc:xliff:document:2.1 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.1 because changing to this only: urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.0 would be completely confusing for a specification labeled 2.1. I think that this would not be confusing at all, it would show people that the schema for core and a number of modules did not change since the last version.  So, only the Matches module would change but we would have to change all URIs (and therefore all tools). I don't think it make sense and it is certainly not modularity. > We said that we do not want to touch core unless > necessary, and we said we are not going to break > core backwards compatibility in 2.x versions. As shown above you don't need to break backward compatibility or even change a single thing in all modules but one to have the tools incapable of working with the new version, even if the changed module is not even present in the document: You just need to change the version of the specification. This is only true if you buy into the argument that namespace URNs need to change even if the namespaces did not change.  > If we are going for 1 we are rendering the schema useless > for validation   I don't have a good answer for validation. But I know going from 2.x to 2.y at each module change is not viable either. The modules have been in appendices and they are now in their own section, they are optional still the TC decide to have them in one spec that fulfills a number of approved business requirements. Some of them are really small and I do not think it makes practical sense to separate them.    >> Solution 1) allows you to keep the core specification and >> schema unchanged while adding/changing/removing modules. >> That is true modularity. > > And it makes the schema useless in protecting modules in > core only applications  If by protecting you mean respecting the PR that says modules MUST be preserved, I think I've addressed that with the suggestion of changing the PR to preserve the elements based on the start of the namespace URI. I do not understand how this is supposed to work. the modules won't be explicitly included in our schema, so tool would be requested to know ad hoc about other namespaces that are not in the schema? Would you say that stuff in namespaces starting with "urn:oasis:names:tc:xliff:" are OK to preserve? But we had a discussion saying that also w3c or similar namespaces would be OK, than we would need to anyway continue maintaining an exception list outside schema, I do not think this is practical..  > ... if we did not care that the standard publication > as result slips to 2015.. > I do care, I hope that others do..  David, it's precisely because I do care about the success of 2.0 that I'm making all those comments. Releasing next month a 2.0 version that is not truly modular will help no-one. I guess if knew at the start what we know now, we could have considered a separate document approach and it might have worked, not sure, but might  I'm sorry those comments come so late and take me so much time to handle, but the alternative of saying nothing would be worst: a bad 2.0 specification. I do not think that we have a bad specification. No specification is ideal. I think we have modularity, certainly more of it than in 1.2 certainly less than ITS 2.0 but that would not be a fair comparison. Our modularity in case of solution 2 would still be better than DITA specializations. > The community will stop waiting if we return to the drawing boards. In my opinion it's not going back to the drawing board: We just have an issue on how to change the modules without affecting the whole specification. We knew all the time that producing minor versions will mean producing an entire new specification. I think that based on OASIS process we cannot possibly say that csprd02 has had lesser impact than csprd01 if we decided to drop all the module from the progressed spec, each of the modules would need to have its own progression. I do not know if anyone has bandwidth to do this, I certainly don't. We've even discussed about a year ago that we do not want to bother with progressing every module individually. This is just one of the consequences. The options are either to accept it or to start a new progression with a new 60 day initial review. The latter seems not acceptable to me..  I don't think the community would like it very much when they realize all tools have to be changed each time a module is added, removed or modified. I think that this is true only if you accept that namespace URN have to be changed even if the schemas did not change.  > You requested to move modules from appendices to the main > body (which was done) and now you request to move them to > separate documents with separate approval process. Yes. Tom's description of the options to solve comment #138 made me realize the specification is not ready to deal with new versions and modularity. That new problem has nothing to do with the other change. I understand how those conflicting request arose, still I think that they are heavily interconnected. Having the modules in the main body as a section is even more inline with OASIS requirements, Martin mentioned that he was not particularly happy about the appendices but admitted that we might have good reasons not have the modules in the main body.  > That would mean that both public reviews we made so far > revealed that the spec is unfit to progress, we would > need to go back to wd01 and have another initial 60 days review. Why deciding to split the main document would make us go back to wd01 for the core? We would just act to fix an issue: we have a single spec defining 9 namespaces and we would decide to have one spec per module. As I said above we would not sustain that we are progressing the same product. In fact a significant portion of features would be dropped. If we decide for what you propose, I will certainly NOT try and argue that we are pushing the same product..   So I sincerely hope that we don't and that you admit that the stakes are too high. In my opinion the main issue is to find a solution for validation. I think this is true and the solution 2 provides it simply through schema 1 that we decided to stick with for some good reasons, such as stability,wide adoption etc. even as we knew about its limited expressivity.  Regards, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, all, >> because changing to this only: >> >> urn:oasis:names:tc:xliff:document:2.0 >> urn:oasis:names:tc:xliff:matches:2.1 >> urn:oasis:names:tc:xliff:glossary:2.0 >> would be completely confusing for a specification labeled 2.1. > > I think that this would not be confusing at all, > it would show people that the schema for core and a > number of modules did not change since the last version. Let me get this straight: In the 2.0 specification we have all schemas with a :2.0 version. Then, for the 2.1 specification we make a modification to the Matches schema which becomes 2.1, we modify the core schema to use that new 2.1 Matches schema, and according what you said above, we do not change the URI of the core schema. So now we have two different schemas for the core with the same URI. That doesn't seem like a good idea to me. I think that with the current system anytime we touch anything we have to change the core schema (and therefore its URI). That means the tools have to change too. Now, let's forget about the issue above and imagine that we're ok with it. The second issue: I'm not sure how the URIs are related to the specifications. We'll have to check with OASIS and http://tools.ietf.org/html/rfc3121 . It seems there is a document id in the URI pattern and maybe it needs to match the version of the specification. I think I'm wrong, but it's something we'll have to verify. But, let's continue, assuming the two problems above are not issues. Following the system you propose David let's go through a little set of changes: We have specification 2.0: xliff:version="2.0" urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.0 urn:oasis:names:tc:xliff:glossary:2.0   Then, with a minor change in Matches we get specification 2.1: xliff:version="2.0" urn:oasis:names:tc:xliff:document:2.0 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.0 Then a necessary but backward compatible change in the core specification 2.2: xliff:version="2.2" urn:oasis:names:tc:xliff:document:2.2 urn:oasis:names:tc:xliff:matches:2.1 urn:oasis:names:tc:xliff:glossary:2.0 Then another minor change is made to Matches, specification 2.3: xliff:version="2.2" urn:oasis:names:tc:xliff:document:2.2 urn:oasis:names:tc:xliff:matches:2.3 urn:oasis:names:tc:xliff:glossary:2.0 Finally a new module is added and we have specification 2.4: xliff:version="2.2" urn:oasis:names:tc:xliff:document:2.2 urn:oasis:names:tc:xliff:matches:2.3 urn:oasis:names:tc:xliff:glossary:2.0 urn:oasis:names:tc:xliff:newmodule:2.4 I think many will find the resulting URIs quite confusing. But regardless... First: How do you know which specification the document follows? Second: You have to follow a fixed set of versions, which means tools using older ones cannot participate, even if their contribution has nothing to do with the new part that has changed. For example. A document is generated from an extractor with: xliff:version="2.2" urn:oasis:names:tc:xliff:document:2.2 urn:oasis:names:tc:xliff:glossary:2.0 Tool_1 adds entries for urn:oasis:names:tc:xliff:newmodule:2.4. that's OK because all current parts of the documents are valid in spec 2.4 when urn:oasis:names:tc:xliff:newmodule:2.4 was introduced. Now, Tool_2 is a second tool in the process and it does some TM leveraging. It knows only how to create urn:oasis:names:tc:xliff:matches:2.1 entries. But, wait, it cannot do this: it's a document following spec 2.4 since there is urn:oasis:names:tc:xliff:newmodule:2.4 entries. Darn, Tool_2 can't add 2.1 matches, even if it know all about core 2.2 and don't care at all about urn:oasis:names:tc:xliff:newmodule:2.4 entries. So: - Tool_1 assumed the document was spec 2.4 because nothing in the document said otherwise. But note that it could be a document build from other spec versions too. - Tool_2, a spec-2.2 tool, could not do its job even if the extractor was possibly following spec 2.2 not 2.4. - The merger (presumably following the same spec as the extractor) may be a spec 2.2 tool and may not be able to process the spec-2.4 file coming back: but we can't know that until the merge occurs. - And during all that time, each tool had to look up all module URIs in the document to try to guess what the specification this document corresponds to. Now you'll tell me: Easy fix: the xliff:version attribute should hold the spec version, not the core version. OK, so we'll end up with a core attribute version="2.4" when the core is actually version 2.2. But at this point we can probably live with that weirdness. (if we go that way I'd suggest to change the name to specVersion to make things less confusing). So now we have less difficulties to know what spec a given document should follow. But we still have the completely artificial limitations that a given module should be of a fixed version just because the document is marked as following a given specification. And all that because our single specification is bound to fixed versions for the core and modules. Again: that is not modularity for me. You could do exactly the same with a single namespace with optional elements/attributes (and that would be a lot less confusing). XLIFF modules should be able to live independently from the core and each other as long as they are 2.x. A tool will have to upgrade its support for all changed modules when it wants to upgrade one. It's totally unnecessary and counter-productive. There are no reason why a document could not have, following the example above, urn:oasis:names:tc:xliff:matches:2.1 and urn:oasis:names:tc:xliff:newmodule:2.4 at the same time: They are completely separate modules. The problems keep piling up. One spec and multiple namespaces just doesn't really work for modularity. >> But I know going from 2.x to 2.y at each module change is >> not viable either. > > The modules have been in appendices and they are now in their own section, > they are optional still the TC decide to have them in one spec that > fulfills a number of approved business requirements. All that is very nice. But it just doesn't work. >> I think I've addressed that with the suggestion of >> changing the PR to preserve the elements based on >> the start of the namespace URI. > > I do not understand how this is supposed to work. the modules > won't be explicitly included in our schema, so tool would be > requested to know ad hoc about other namespaces that are > not in the schema? I don't understand what you don't understand :) The tool just check the start of the namespace and can see if it's an XLIFF TC namespace or not: no need to involve schema for this. Even core-only processors can do this. > But we had a discussion saying that also > w3c or similar namespaces would be OK, than we would > need to anyway continue maintaining an exception > list outside schema, I do not think this is practical..  Well currently such namespaces can get nuked. Do we actually have a resolution recording those exceptions? If we do then there should be a PR in this version of the core for this. And if a PR in the spec, then the tool could look for those URI (or start of URIs) as well. > I think we have modularity, certainly more of it than > in 1.2 certainly less than ITS 2.0 but that would not > be a fair comparison. > Our modularity in case of solution 2 would still be > better than DITA specializations. Not sure what ITS or DITA have to do with XLIFF, but what we have is a better specialization of the elements than in 1.2: they are groups by types of functionalities. But that is not being modular. >> I don't think the community would like it very much when >> they realize all tools have to be changed each time a >> module is added, removed or modified. > > I think that this is true only if you accept that namespace > URN have to be changed even if the schemas did not change.  Yes, and that is always true. Cheers, -yves