|
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
|