OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all, One last question to close that specific topic. (just making sure we have a clear path forward). Now that we have a solution for the schemas/spec what will happened to the version number when we have a new specification? Let's say we add a new module: - We have to change the spec document since we add the module there I presume. - But none of the namespaces changes, so they all stay at 2.0 (including the core). - Does the spec document goes to 2.1? or something like 2.0.a? - and the version attribute changes to the spec version. --> one issue: that attribute is part of the core, if we change it we change the core schema... My question I suppose is: do we need a version attribute at all? Since that info now would make sense only per namespace. The overall version of the spec is rather moot since it can have modules defined on previous versions. Cheers, -ys

Hi Yves, I think having a version on the core makes sense. It is an easy way for processors to identify what to expect from the core even if they do not support Namespaces in XML. Supporting modules but not namespaces seem like a bad idea so for the modules using the namespace as the version is probably ok. I don't think we necessarily need to release a new version of the whole specification to add a new module, as long as it has a TC namespace, now that we have the URN matching rule and no explicit references from core to modules. I agree that it might seem odd that a new module is a separate document while the existing ones are not but there is no technical obstacle any more. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: den 4 december 2013 14:39 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - version attribute > > Hi all, > > One last question to close that specific topic. > (just making sure we have a clear path forward). > > Now that we have a solution for the schemas/spec what will happened to > the version number when we have a new specification? > > Let's say we add a new module: > > - We have to change the spec document since we add the module there I > presume. > - But none of the namespaces changes, so they all stay at 2.0 (including the > core). > - Does the spec document goes to 2.1? or something like 2.0.a? > - and the version attribute changes to the spec version. > --> one issue: that attribute is part of the core, if we change it we change the > core schema... > > My question I suppose is: do we need a version attribute at all? Since that > info now would make sense only per namespace. The overall version of the > spec is rather moot since it can have modules defined on previous versions. > > Cheers, > -ys > > > > --------------------------------------------------------------------- > 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 Fredrik, all, > I don't think we necessarily need to release a new version of > the whole specification to add a new module, as long as it has > a TC namespace, now that we have the URN matching rule and no > explicit references from core to modules. Indeed. If the new modules go in separate documents, then we should be ok: no changes on 2.0. But if we do make a modification to one of the 2.0 modules, or remove one: the same questions remain. What will be the changes then? Cheers, -ys

Hi Yves, all From a technical perspective I don't think there is a difference. Nor that there is a difference between publishing as one document or multiple documents. It might sound strange at first but I think that is the case. This is based on my possibly incorrect assumption that a standard cannot be un-published. Once it is published as a standard it will exist as long as someone has a copy of the normative document. It might be abandoned or updated or there might be a recommendation to not use it but the published version will forever be a standard. For the update case if we release 2.0 as a single document including foo-module-2.0 we could release a separate document with foo-module-3.0 at any time. Version 2.0 of the module would still exist as a standard, there would just be a successor standard published separately from the core. As there is no requirement to support any module at all, a tool is free to only support the core plus the separately published version of the module. It could at its own choose to support both the 2.0 and the 3.0 version of the module or none. I don't think there is a material change if we release core as one standard and the modules as separate standards. There would still be both a 2.0 and a 3.0 version of the module that could both be used with the core. As they would use their namespace as the version they could even co-exist in the same document. Not sure that the last point is desirable though. For the removal case I don't think we can ever remove a module regardless of how it is published, we can declare it abandoned or superseded. But the one we once published will still exist. So again same document or multiple documents make no technical difference. I think the main issue will arise when we want to make a revision of the core after we made a revision of one of the modules separately. At that point we would likely have to remove that module completely from the core + modules document before it could be published. At that point breaking all modules out might be a good thing to do. We have no language in the modules as to which versions of XLIFF they apply to. I think this might be a bigger technical issue. If kept as one document it is apparent that they are supposed to work with the core version they are published together with. If published separately it becomes a little harder, do we want to lock the module to a specific set of supported core versions or leave it open (possibly with a bound like 2.x). If we lock it we will need to release new versions of the modules when we release a new core so they can include that in the list of supported core versions. This would allow a future version of XLIFF to not support a "removed" module by simply not updating that module to include the new core as supported. But almost the same effect would happen if we published an updated core without that module in the case of one document with both core and modules. An official registry of modules could be the solution to the what module version is supported with what core version problem. So we should probably include that if we start looking at a registry. What OASIS rules say on this I don't know, but we should probably try to find out. I feel that if possible we should avoid making such a drastic change like splitting the standard into many standards at this point. It is more of an administrative problem than a technical or implementation problem. And it would probably delay the process quite a bit. But if there are some OASIS rules that would make future progress very difficult it might be a price we should pay now rather than forever later. Regards, Fredrik Estreen > Hi Fredrik, all, > > > I don't think we necessarily need to release a new version of the > > whole specification to add a new module, as long as it has a TC > > namespace, now that we have the URN matching rule and no explicit > > references from core to modules. > > Indeed. If the new modules go in separate documents, then we should be > ok: no changes on 2.0. > > But if we do make a modification to one of the 2.0 modules, or remove one: > the same questions remain. What will be the changes then? > > Cheers, > -ys > > > > --------------------------------------------------------------------- > 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 Fredrik, all, My first concern is about the version value: It is currently defined as a fixed value in the schema of the core. So whenever we publish a new version we must change the schema of the core, and therefore increment the core version too. That leads to having tools not working with the new namespace URI just because the specification version has changed. So I would propose to change the declaration of the version attribute to make it and unspecified xs:string in the schema and define its value in the specification only. Now, as for the different types of changes and how to address them. I think I agree with most of what you are saying Fredrik. At the end it looks like if the schemas are independent and we don't have a fixed set of modules forced with one given specification version, we can have a single specification document for a while. Cheers, -yves regardless I think my concern lies with the way a tool will have to handle different
Original Message----- From: Estreen, Fredrik [ mailto:Fredrik.Estreen@lionbridge.com ] Sent: Thursday, December 5, 2013 9:08 AM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - version attribute Hi Yves, all From a technical perspective I don't think there is a difference. Nor that there is a difference between publishing as one document or multiple documents. It might sound strange at first but I think that is the case. This is based on my possibly incorrect assumption that a standard cannot be un-published. Once it is published as a standard it will exist as long as someone has a copy of the normative document. It might be abandoned or updated or there might be a recommendation to not use it but the published version will forever be a standard. For the update case if we release 2.0 as a single document including foo-module-2.0 we could release a separate document with foo-module-3.0 at any time. Version 2.0 of the module would still exist as a standard, there would just be a successor standard published separately from the core. As there is no requirement to support any module at all, a tool is free to only support the core plus the separately published version of the module. It could at its own choose to support both the 2.0 and the 3.0 version of the module or none. I don't think there is a material change if we release core as one standard and the modules as separate standards. There would still be both a 2.0 and a 3.0 version of the module that could both be used with the core. As they would use their namespace as the version they could even co-exist in the same document. Not sure that the last point is desirable though. For the removal case I don't think we can ever remove a module regardless of how it is published, we can declare it abandoned or superseded. But the one we once published will still exist. So again same document or multiple documents make no technical difference. I think the main issue will arise when we want to make a revision of the core after we made a revision of one of the modules separately. At that point we would likely have to remove that module completely from the core + modules document before it could be published. At that point breaking all modules out might be a good thing to do. We have no language in the modules as to which versions of XLIFF they apply to. I think this might be a bigger technical issue. If kept as one document it is apparent that they are supposed to work with the core version they are published together with. If published separately it becomes a little harder, do we want to lock the module to a specific set of supported core versions or leave it open (possibly with a bound like 2.x). If we lock it we will need to release new versions of the modules when we release a new core so they can include that in the list of supported core versions. This would allow a future version of XLIFF to not support a "removed" module by simply not updating that module to include the new core as supported. But almost the same effect would happen if we published an updated core without that module in the case of one document with both core and modules. An official registry of modules could be the solution to the what module version is supported with what core version problem. So we should probably include that if we start looking at a registry. What OASIS rules say on this I don't know, but we should probably try to find out. I feel that if possible we should avoid making such a drastic change like splitting the standard into many standards at this point. It is more of an administrative problem than a technical or implementation problem. And it would probably delay the process quite a bit. But if there are some OASIS rules that would make future progress very difficult it might be a price we should pay now rather than forever later. Regards, Fredrik Estreen > Hi Fredrik, all, > > > I don't think we necessarily need to release a new version of the > > whole specification to add a new module, as long as it has a TC > > namespace, now that we have the URN matching rule and no explicit > > references from core to modules. > > Indeed. If the new modules go in separate documents, then we should be > ok: no changes on 2.0. > > But if we do make a modification to one of the 2.0 modules, or remove one: > the same questions remain. What will be the changes then? > > Cheers, > -ys > > > > --------------------------------------------------------------------- > 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 Yves, Sorry for missing this point in your original question. I completely agree that it would make sense to not encode the version in the schema itself. Changing it to an unconstrained xs:string and only defining the value in the specification document sounds right to me. I think we want to be able to make non-schema impacting changes without having to change the schema and still have a way to increase the version. Regards, Fredrik Estreen >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: den 5 december 2013 21:03 > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - version attribute > > Hi Fredrik, all, > > > My first concern is about the version value: It is currently defined as a fixed > value in the schema of the core. > So whenever we publish a new version we must change the schema of the > core, and therefore increment the core version too. That leads to having > tools not working with the new namespace URI just because the > specification version has changed. > > So I would propose to change the declaration of the version attribute to > make it and unspecified xs:string in the schema and define its value in the > specification only. > > Now, as for the different types of changes and how to address them. I think I > agree with most of what you are saying Fredrik. > > At the end it looks like if the schemas are independent and we don't have a > fixed set of modules forced with one given specification version, we can > have a single specification document for a while. > > Cheers, > -yves > > > > > regardless I think my concern lies with the way a tool will have to handle > different > >
Original Message----- > From: Estreen, Fredrik [ mailto:Fredrik.Estreen@lionbridge.com ] > Sent: Thursday, December 5, 2013 9:08 AM > To: Yves Savourel; xliff@lists.oasis-open.org > Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle > Attribution) - version attribute > > Hi Yves, all > > From a technical perspective I don't think there is a difference. Nor that > there is a difference between publishing as one document or multiple > documents. It might sound strange at first but I think that is the case. This is > based on my possibly incorrect assumption that a standard cannot be un- > published. Once it is published as a standard it will exist as long as someone > has a copy of the normative document. It might be abandoned or updated or > there might be a recommendation to not use it but the published version will > forever be a standard. > > For the update case if we release 2.0 as a single document including foo- > module-2.0 we could release a separate document with > foo-module-3.0 at any time. Version 2.0 of the module would still exist as a > standard, there would just be a successor standard published separately > from the core. As there is no requirement to support any module at all, a tool > is free to only support the core plus the separately published version of the > module. It could at its own choose to support both the 2.0 and the 3.0 > version of the module or none. I don't think there is a material change if we > release core as one standard and the modules as separate standards. > There would still be both a 2.0 and a 3.0 version of the module that could > both be used with the core. As they would use their namespace as the > version they could even co-exist in the same document. Not sure that the > last point is desirable though. > > For the removal case I don't think we can ever remove a module regardless > of how it is published, we can declare it abandoned or superseded. But the > one we once published will still exist. So again same document or multiple > documents make no technical difference. > > I think the main issue will arise when we want to make a revision of the core > after we made a revision of one of the modules separately. At that point we > would likely have to remove that module completely from the core + > modules document before it could be published. At that point breaking all > modules out might be a good thing to do. We have no language in the > modules as to which versions of XLIFF they apply to. I think this might be a > bigger technical issue. If kept as one document it is apparent that they are > supposed to work with the core version they are published together with. If > published separately it becomes a little harder, do we want to lock the > module to a specific set of supported core versions or leave it open (possibly > with a bound like 2.x). If we lock it we will need to release new versions of > the modules when we release a new core so they can include that in the list > of supported core versions. This would allow a future version of XLIFF to not > support a "removed" module by simply not updating that module to include > the new core as supported. But almost the same effect would happen if we > published an updated core without that module in the case of one document > with both core and modules. > > An official registry of modules could be the solution to the what module > version is supported with what core version problem. So we should probably > include that if we start looking at a registry. > > What OASIS rules say on this I don't know, but we should probably try to find > out. > > I feel that if possible we should avoid making such a drastic change like > splitting the standard into many standards at this point. > It is more of an administrative problem than a technical or implementation > problem. And it would probably delay the process quite a bit. But if there are > some OASIS rules that would make future progress very difficult it might be a > price we should pay now rather than forever later. > > Regards, > Fredrik Estreen > > > Hi Fredrik, all, > > > > > I don't think we necessarily need to release a new version of the > > > whole specification to add a new module, as long as it has a TC > > > namespace, now that we have the URN matching rule and no explicit > > > references from core to modules. > > > > Indeed. If the new modules go in separate documents, then we should be > > ok: no changes on 2.0. > > > > But if we do make a modification to one of the 2.0 modules, or remove > one: > > the same questions remain. What will be the changes then? > > > > Cheers, > > -ys > > > > > > > > --------------------------------------------------------------------- > > 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 > > > > > > --------------------------------------------------------------------- > 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 >