Re: [ubl] Discussion of substitution groups

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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: ubl@lists.oasis-open.org

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