Title: Re: [ubl] Discussion of substitution groups
Mark,
What are the considerations about not
changing
the namespace in minor versions?
Here are some I'd offer:
1. It might be that the schemaLocation would
be
relied on to show which schema exactly an
instance
related to.
2. It would be possible to make the schemaLocation
vague so that schemas could be switched
for
validation.
3. Having only the last relevant major
namespace
and a similarly vague schemaLocation would
leave
the need to determine the relevant schema in
some
other way. It would make it necessary to provide
some other means to show
that an instance is only
valid against a minor
version schema.
4. From 3. above there would be a tendency to
do
the same with customisations (to make it
necessary
to provide some other means to show that an
instance
is only valid against a custom schema)
5. If 'some other means' in points 3 and 4
were
insufficient it might
possibly break non-repudatiability
in certain situations: It would be impossible to
assert
with certainty that any instance
were 'invalid' (since
it could be counter asserted that it was
properly
valid against some other schema than that
in the
namespace).
6. If 'some other means' in points 3 and 4
were
insufficient then the effect would be very
similar
to that of having unqualified xsd:any in the worse
cases: For example, it might then be that external
documents are necessary to determine and record
for posterity the precise schema behind the instance.
This would possibly even be illegal in some regimes.
At best it might make costs of implementation and
especially of long-term storage higher since extra
documents besides the schema and the instances
would have to be stored long-term and correlated
reliably over a long period.
7. It might prove harder to determine the exact
semantic meaning of a particular BIE if the
exact schema to which the instance related could
not be determined.
8. The problem in 7 would be even worse if the
same rules being applied to minor versions were
applied to customised schemas. Here there is
less reason to expect that the semantics do not
change between original and custom schema.
9. Further problems would be created for
customisers: custom schemas based on one version
would typically need to be updated as new minor
versions are released and tying the custom schema
to the right minor or major version schema could
become a nightmare similar to 'DLL HELL'. [I've
emphasised the latter term as it might act as a
pointer to those developers, etc unfortunately
familiar with the subject of the problems which
might be created by getting this wrong.]
10. Going back to 3., it has been hard enough
to seek a standarisation and consistent
implementation of namespace methodologies
across tools, etc but having to establish yet
another means (perhaps even duplicating
the functionality of the former) would take years
and would need a similarly comelling business
case. I doubt whether even the CCTS would
be sufficient for this. I doubt even more whether
the version attribute could do the job. I doubt
more still that it could be done with a UBL BIE
for version.
11. I hope nobody suggests that the version
annotation in the schema be used !! :-)
All the best
Steve
----- Original Message -----
From:
CRAWFORD, Mark
To:
Sent: Wednesday, July 20, 2005 11:50
AM
Subject: RE: [ubl] Discussion of
substitution groups
>In transactional messaging, there can be the
risk of legal consequences if
you don't know exactly which version of
a message Schema applies to an
message instance, since each Schema
version is like a different version of
a contract, and you introduce
a business risk of you decide do something
under the terms of a
contract, without checking which version of the
contract actually
applies.
>The upshot is that each message instance really should
identify which
Schema, and which version of that Schema, applies to
it. The most popular
way to do this is to have a unique
namespace for each version of each
Schema. The way I like to do
it, sometimes in addition to the namespace
technique, is to provide
top-level attributes which have a fixed value
that is required to
appear, and which identify the Schema and version.
Sometimes
people try to use the 'schemaLocation' to provide Schema
version
information, but this is a fragile technique that I don't
recommend in
general.
Remember - ATG is just not using minor
versioning of the namespaces. They continue to use minor versioning of
the schema. The namespaces is only a conceptual holder used to
differentiate conflicting
names.
---------------------------------------------------------------------
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
