OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl] Discussion of substitution groups

Title: Re: [ubl] Discussion of substitution groups
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
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
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
----- Original Message -----
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 

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]