[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - version attribute
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]