RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution) - version attribute

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

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
>