[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Specialised DataTypes Schema Module
Specialised DataTypes Schema ModuleThe next Co-ordination meeting will be preceded by a meeting to discussthe content of the Specialised DataTypes Schema Module. In particularTim has suggested that, since it does not seem to contain anything notfound 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 havein draft 8.3 but without the SDT Schema. The only document schema includedin 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 boththe document schema modules (just the invoice in this example) and to theCommon 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 tocompare the results as closely as possible with draft-8.3.)The sample invoice (a maximal elements and attributescontent sample, generated withXML 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), actuallythe invoice is valid (using XML Spy - XSD spec and other parsers ??) without the namespacechange 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 moduleswhere, at present, either UDT is used for the code's type or the code is new to UBLaltogether. Such a change would appear to not break backwards compatibility withthe 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 termsof the need to preserve backwards compatibilty?2. Does backwards compatibilty only apply to instances? Does not in some waysapply to schemas even in cases where instances can be unaffected? Is the removalof the SDT Schema Module going to adversely affect backwards compatibility whena new codelist needs to be added or one which was based on UDT is change to havinga new Codelist Schema Module as the base of its type? After all, to implement thefacilities offered by substitutionGroup / abstract element Schema architecture one mighthave 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 newnamespace be introduced to the Document Schema Modules and the Common AggregateSchema Modules does not necessarily mean that these namespaces have to be changedin the instances. Though one might wish that it did, it might have negative ramificationson the backwards compatibility.Adding a codelist means adding a new namespace and a new prefix to the SDT at presentbut not necessarily elsewhere.Without the SDT, the namespace prefix has to be added to the type on which aCode 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 Iwouldn't be very surprised if it did in some situations such as with XPaths and XSLTStylesheets 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 needto go updating namespaces and prefixes in Schema Modules which appeared to be immunebefore when adding or, in some cases, changing Codelist Modules.ConclusionsI would prefer, in the light of Jon's recent statement "...taking care to construct 1.0 in away 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 assurancethat it will not cause foreseeable problems with 1.1I think it may be worth getting extra advice regarding the effect of changing a codelist schemanamespace on an invoice with regards to backwards compatibilty too. There is no adverse affect inXML Spy and StylusStudio but how about other parsers and XSLT stylesheets? Have we any comebackabout this from LMI or Ken? The question is - changing a namespace in a Schema which is not directlyreferenced by an instance - does it ever cause problems for such instances in a way that somewould 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 beto 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 andgreater complexity and maintenance). I know I sought to assure that this wouldn't be necessarywhen considering adding substitutionGroups, etc for 1.1 but without the SDT I wouldn't be so sure.Stephen Green
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
-- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]