Re: [ubl] Version number in file names

[stephen.green@systml.co.uk]

Hi Ken

Here's my take on it:

The issue may be, with UBL, that we use a urn-type namespace;
that is, one which doesn't in itself resolve to anything since
it can't double as a location.

This means that it should be possible to 'point' to some sort
of location from an instance other than by use of the namespace.
So the only way we provide for this is with the filename and/or
permanent url.

I'm very much in favour of the approach taken elsewhere of using
an aliasing system whereby a given url can always point to the
latest schema: this involves providing the permanent url with
an alias which resolves automatically (via the web server) to the
latest minor version. If that permanent url is used in the instance
(schemaLocation in UBL's case) then it is immune to minor version
changes (which should always be backwards compatible).

As ebXML TC enlightened me, there is a nice finishing touch to this
in that it should also be possible to 'point' with a more specific
url in the schemaLocation to the particular minor version you want.

The latter twist could be helped by having the actual files contain
the minor version and then asking the OASIS administrators to
provide an alias on the web server without the minor portion which
points to the latest minor version file. Alternatively an alias could
perhaps point by a specific url to the latest version even without
the need to include that minor version id in the filename but by using
folders with the minor version - perhaps a more 'standard' way.

EbXML-BP is an example of this but there the namespace itself resolves
so less emphasis on the filename itself is needed I suppose.

All seems good to me if it allows instances to remain neutral about
minor version (particularly apparent as an advantage if they use the
major version) and immune from minor version changes completely by
being less specific in their schemaLocation attribute content but
especially being less specific in trading agreement references needed
to specify the standard and version used. Then trading partner agreements
don't have to change (or software) whenever a new minor version is issued.

Why should I have to provide in validating software and instances (and TPAs)
for every minor version and add changes whenever a new one comes out when
with the above I can just use the latest minor version without impact on
the systems. The only impact is then the actual value-delivering one - that
of use of the latest changes should instances be accepted which include them
And if I don't want that possibility I can exclude it by being more specific
in my TPAs about the version(s) allowed (but still use the latest schema files
for my validation if they are truly backwards compatible in that way).

- my more lengthy, thought out response :-)

All the best

Steve





Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:

> At 2006-07-10 12:08 -0600, stephen.green@systml.co.uk wrote:
>> 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.
>
> Oh!  Of course ... in the instance it would be a problem.  Thank you Stephen.
>
> I'm anticipating that minor version schemata will be delivered in toto
> with self-referential integrity, thus I wasn't anticipating any
> problems that a suite of schema files would be able to validate an
> arbitrary instance.
>
>> 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.
>
> How could we measure this?
>
> I ask because I believe there is tremendous gain in keeping the same
> namespace for minor versions of existing information items (and I've
> suggested using a new minor namespace for new information items
> introduced in minor versions), but I've always felt strongly *from a
> file management perspective* that the artefacts themselves would have
> unique file names.
>
> A number of XML cognoscenti firmly believe it was wrong in XML document
> type declarations to have to identify the model of constraints against
> which a document is always tested.  Constraints should be tested
> dynamically based on situational requirements.  Indeed using RELAX-NG
> one is *obliged* to reference the set of constraints from outside of
> the document and one cannot embed in a document a reference to said
> constraints.
>
> I think xsi:schemaLocation should be considered harmful and that good
> practice prohibits its use ... but I acknowledge that cannot prevent it
> from being used.
>
> I would like to propose that we explicitly break the compatibility of
> xsi:schemaLocation in favour of file management and that we recommend
> UBL instances not use xsi:schemaLocation ... I even suspect we'll have
> validation issues with our schema expressions when xsi:schemaLocation
> is used in a document, but right now I don't have the time to test this
> (I want to answer your post immediately as I think this is an important
> discussion).
>
> Consider that Joe Public uses xsi:schemaLocation to point to his local
> version of the schema and he sends the instance to Jane Citizen who
> tries to work with the instance in her environment.  The instance is
> "broken" from her perspective as the instance points to a non-existent
> schema in her environment.  We are trying to build an international
> interoperable environment, thus I think we are justified in debating
> the prohibition of xsi:schemaLocation.
>
> At the least I'd like us to consider forcing file name distinction.
>
> I vote for "globally correct" over "localized convenience".
>
> Thank you, Stephen, for bringing this important issue to light.
>
> . . . . . . . . . Ken
>
> --
> Registration open for UBL training:    Montréal, Canada 2006-08-07
> Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
> Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
> World-wide corporate, govt. & user group UBL, XSL, & XML training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> 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