Specialised DataTypes Schema Module

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Specialised DataTypes Schema Module




From: "Stephen Green" <>
To: <>
Date: Tue, 16 Mar 2004 22:04:46 -0000









Specialised DataTypes Schema 
Module
 
The next Co-ordination meeting will be preceded by 
a meeting to discuss
the content of the Specialised DataTypes Schema 
Module. In particular
Tim has suggested that, since it does not seem to 
contain anything not
found already in other Schema modules, it may be 
that we can do without it.
 
In preparation for this discussion I have built a 
set of Schemas, as we have
in draft 8.3 but without the SDT Schema. The only 
document schema included
in this is the invoice schema. An invoice instance 
was produced too.
 
The changes necessary were as follows:
 
1. The namespaces for the codelist schema 
modules had to be added to both
the document schema modules (just the invoice in 
this example) and to the 
Common Aggregate Components Schema Module, along 
with the schema locations.
 
2.  References to Codes in these, where the 
code has a codelist Schema Module in UBL,
(but, importantly, *not* 
where it doesn't) have to be changed from 
 
                       
'type="sdt:CurrencyCodeType"'
to, 
say,           
 'type="cur:DerivedCodeType"'.
 
(I did not attempt to amend the use of the name 
'DerivedCodeType' since I wished to 
compare the results as closely as possible with 
draft-8.3.)
 
The sample invoice (a maximal elements and 
attributescontent sample, generated with 
XML Spy) was valid both against the original 
schemas and against the new ones since,
although, ideally the namespaces should change (sdt 
removed and cur added), actually
the invoice is valid (using XML Spy - XSD spec and 
other parsers ??) without the namespace 
change since the namespaces of the codes' types are 
effectively hidden in the instances.
 
 
This then seems to support the case for successful 
removal of the SDT Schema module.
 
However, a major concern would 
be:
 
1. What happens if UBL or other groups wish to add 
new codelist schema modules
where, at present, either UDT is used for the 
code's type or the code is new to UBL
altogether. Such a change would appear to not break 
backwards compatibility with
the SDT Schema Module in place, as at present (or 
with the substitutionGroup design),
but would this still be so with the SDT 
removed?
 
Such a change would be encouraged if 
substitutionGroups were introduced for 1.1 say.
Would this removal of the SDT prevent the later use 
of substitutionGroups in terms
of the need to preserve backwards 
compatibilty?
 
2.  Does backwards compatibilty only apply to 
instances? Does not in some ways
apply to schemas even in cases where instances can 
be unaffected? Is the removal
of the SDT Schema Module going to adversely affect 
backwards compatibility when
a new codelist needs to be added or one which was 
based on UDT is change to having
a new Codelist Schema Module as the base of its 
type? After all, to implement the
facilities offered by substitutionGroup / abstract 
element Schema architecture one might
have to create a codelist Schema module where 
previously there was only the UDT.
 
In answer:
 
Adding a codelist schema module that didn't exist 
before, or requiring that a new
namespace be introduced to the Document Schema 
Modules and the Common Aggregate 
Schema Modules does 
not necessarily mean that these namespaces have to be changed
in the instances. Though one might wish that it 
did, it might have negative ramifications
on the backwards compatibility.
 
Adding a codelist means adding a new namespace 
and a new prefix to the SDT at present
but not necessarily elsewhere.
 
Without the SDT, the namespace prefix has to be 
added to the type on which a 
Code element is based. So the namespace and prefix 
have to be added to the CAC and,
where appropriate, the Document Schema 
Modules.
 
They do not have to be added to the instance (to my 
knowledge), but they could be. 
I do not think that 
adding them would necessarily cause instance problems, though I 
wouldn't be very surprised if it did in some situations 
such as with XPaths and XSLT 
Stylesheets as well 
as some applications. I'd really want to check it with he experts
- and do we have time to do so?
 
Even if there were no instance problems that we 
could foresee, there is still the need
to go updating namespaces and prefixes in Schema 
Modules which appeared to be immune 
before when adding or, in some cases, changing 
Codelist Modules.
 
Conclusions
 
I would prefer, in the light of Jon's recent 
statement "...taking care to construct 1.0 in a 

way that will allow the 
adoption of substitution groups in 1.1 without breaking 1.0 
instances",
that we *not* remove the SDT Schema Module at this 
stage without further expert assurance
that it will not cause foreseeable problems with 
1.1
 
I think it may be worth getting extra advice 
regarding the effect of changing a codelist schema
namespace on an invoice with regards to backwards 
compatibilty too. There is no adverse affect in 
XML Spy and StylusStudio but how about 
other parsers and XSLT stylesheets? Have we any comeback 
about this from LMI or Ken? The question is - 
changing a namespace in a Schema which is not directly
referenced by an instance - does it ever cause 
problems for such instances in a way that some
would view as meaning that such changes break 
backwards compatibilty?
 
One way round this, if the SDT were removed (and it 
might not hurt even if it weren't), might be 
to create schema modules of all our codelists so that we don't get problems adding these 
later.
This doesn't seem ideal though (we did it for beta 
but it meant a large set of schemas and
greater complexity and maintenance). I know I 
sought to assure that this wouldn't be necessary
when considering adding substitutionGroups, etc for 
1.1 but without the SDT I wouldn't be so sure.
 
 
 
Stephen Green
 
 
 
 
 
 
 
xsd-no-sdt.zip





Follow-Ups:

Re: [ubl] Specialised DataTypes Schema Module
From: Tim McGrath <>








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]