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: Specialised DataTypes Schema Module


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



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