Re: [ubl] Version number in file names

[stephen.green@systml.co.uk]

Hi Jon

Just a hurried response, sorry:

The advantage in having no difference in the filename is that
there is then no need to change the schemaLocation in the instance
if a new minor version becomes active. Otherwise there would be
unnecessary incompatibility for minor versions in instances which
are otherwise agnostic about which minor version they use (where
backwards compatibility is concerned). Otherwise there is little
to be gained from keeping the same namespace for minor versions
(and using the UBLVersionID element) when schemaLocation is used
in instances, as is the usual case with UBl instances it seems.

All the best

Steve




Quoting jon.bosak@sun.com:

> Hello UBL TC,
>
> In putting together the initial test build for the next public
> review, I was struck by how strange it seems to have just "2"
> instead of "2.0" in the file names.
>
> We discussed version numbering in namespace URIs for weeks, and I
> think we're all clear on why we decided to use "2" instead of
> "2.0" in the URIs.  But the decision to do the same for file names
> seems to have been an afterthought.  In the minutes for 9 November
> 2005 we have simply the following:
>
>    SG: [Regarding the decision to use "2" rather than "2.0" in
>    namespaces] We should drop the minor version number from the
>    file names as well.
>
>    AGREED to use "2" in the major version file names rather than
>    "2.0".
>
>    AGREED that the version number is required.
>
> Now I'm wondering whether we really had reasons beyond simple
> parallelism in applying the same rule to the file names as the
> namespace URIs.  And it's easy to think of scenarios in which we
> will want to revise the schemas while still maintaining backward
> compatibility, that is, scenarios in which we will want "2.1" in a
> file name.
>
> Can someone please remind me why we're omitting the minor version
> number from file names?
>
> Jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>