[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ssc] Re minor version Schema design
Folks in SSC Greetings Please find attached a prototype set of Schemas with the design I think we are proposing for 1.1. It is based, again, on the addition of a BBIE called an InspectionDate but this time to not just Invoice and InvoiceLine but also to Item (which is contained by InvoiceLine). A possibility for a further prototype might be to change the UBLAmount SDT to use an updated version of the ISO Currency Codelist. This would require an updated SDT Schema module and the ripple effect to the Amount datatypes which use the UBLAmount. A question: should the previous document Schema still be imported into the new document Schema module even if it isn't used there in XSD derivation? The side effect is that it then creates a second way by which an instance can reference the previous version Schemas (as seen in the example "Invoice1.0-with-1.1-prototype-11-sdg.xml"). I'd propose we seek agreement on Thursday's call as to whether to proceed with this design by proposing or recommending it to the TC (Atlantic Call/NDR Team). All the best Steve >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 21/03/05 11:44:47 >>> Greetings SSC Re minor version Schema design ---------------------------------------- I've been looking through the ATG2 NDR and the UBL NDR and thinking about the options available to us, as discussed, and it seems to me we'd best do the following: ********************************************** Redeclare all elements and complexTypes for 1.1 BIEs and avoid extension (just add a new BBIE, say, to the end of an ABIE's redeclaration) as in ATG2's NDR and not use restriction except to create a new BIE (with a new name) from another - again as in ATG2's NDR. ********************************************** [Reasons: Tony has pointed out the need to redeclare everything to give each BIE the new namespace and allow reuse in the following minor version (without having to import every single previous version to avoid having to declare too many multiple namespaces in an instance) I have shown that we cannot have a non-derived ABIE which is associated with a derived BIE, which very much limits import/derivation use David has pointed out the variation on the relevant rules in the ATG2 NDR where *for BIEs* extension is avoided and restriction is limited to renamed BIEs only. A key advantage is that the instances would only need new namespaces without the need for a different textual structure or extra prefixes here and there.] Do others in SSC agree with this design? If so we'd need to get feedback on this from NDR Team/TC and fairly certainly have extra NDRules produced to eliminate the human choices in the design. All the best Steve >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 18/03/05 15:14:03 >>> Amendment: I think, for extension, the redeclared InvoiceLineType would need an extra intermediate name since it would otherwise appear twice in the same namespace. This might then need a new Naming and Design Rule for the intermediate complexType name. [original message is at http://lists.oasis-open.org/archives/ubl-ssc/200503/msg00013.html ] >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 03/18/05 13:05 PM >>> ... possibly here a redeclaration of the 1.0 elements and global complexTypes under the 1.1 namespace ... <xsd:element name="InvoiceLine" type="InvoiceLineType"/> ... redeclaration of the InvoiceLineType ... <!-- extension of InvoiceLineType --> <xsd:complexType name="InvoiceLineType"> <xsd:complexContent> <xsd:extension base="InvoiceLineType"> <xsd:sequence> <xsd:element ref="cbc:InspectionDate" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> ... further redeclarations of the 1.0 elements and global complexTypes under the 1.1 namespace ...
xsd-derivation-1-1-prototype-11-sdg.zip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]