[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] [ver] a prototype that works
Folks, Looking again at the prototype design and comparing with Arofan's the main difference is that Arofan's demonstrates that there is no need for the change to the complex type name. I had:- <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="Invoice-2.1" xmlns:in="Invoice-2.0" xmlns:cac="CommonAggregateComponents-2.0" xmlns:cac11="CommonAggregateComponents-2.1" xmlns:cbc="CommonBasicComponents-2.0" xmlns:cbc11="CommonBasicComponents-2.1" targetNamespace="Invoice-2.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.1-prototype-ver-sdg-1"> <!-- ===== Imports ===== --> <xsd:import namespace="Invoice-2.0" schemaLocation="../../xsdrt-2-0-prototype-ver-sdg-1/maindoc/Invoice-2.0.xsd" /> <xsd:import namespace="CommonAggregateComponents-2.1" schemaLocation="../common/CommonAggregateComponents-2.1.xsd"/> <xsd:import namespace="CommonBasicComponents-2.1" schemaLocation="../common/CommonBasicComponents-2.1.xsd"/> <!-- ===== Element Declarations ===== --> <!-- ===== Root Element ===== --> <xsd:element name="Invoice" type="InvoiceBaseType" substitutionGroup="in:Invoice"/> <!-- ===== Type Definitions ===== --> <!-- ===== Aggregate Business Information Entity Type Definitions ===== --> <!-- example addition 1 - InspectionDate added to Invoice --> <xsd:complexType name="InvoiceBaseType"> <xsd:complexContent> <xsd:extension base="in:InvoiceType"> <xsd:sequence> <xsd:element ref="cbc11:InspectionDate" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema> But this could otherwise be:- <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="Invoice-2.1" xmlns:in="Invoice-2.0" xmlns:cac="CommonAggregateComponents-2.0" xmlns:cac11="CommonAggregateComponents-2.1" xmlns:cbc="CommonBasicComponents-2.0" xmlns:cbc11="CommonBasicComponents-2.1" targetNamespace="Invoice-2.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.1-prototype-ver-sdg-2"> <!-- ===== Imports ===== --> <xsd:import namespace="Invoice-2.0" schemaLocation="../../xsdrt-2-0-prototype-ver-sdg-2/maindoc/Invoice-2.0.xsd" /> <xsd:import namespace="CommonAggregateComponents-2.1" schemaLocation="../common/CommonAggregateComponents-2.1.xsd"/> <xsd:import namespace="CommonBasicComponents-2.1" schemaLocation="../common/CommonBasicComponents-2.1.xsd"/> <!-- ===== Element Declarations ===== --> <!-- ===== Root Element ===== --> <xsd:element name="Invoice" type="InvoiceType" substitutionGroup="in:Invoice"/> <!-- ===== Type Definitions ===== --> <!-- ===== Aggregate Business Information Entity Type Definitions ===== --> <!-- example addition 1 - InspectionDate added to Invoice --> <xsd:complexType name="InvoiceType"> <xsd:complexContent> <xsd:extension base="in:InvoiceType"> <xsd:sequence> <xsd:element ref="cbc11:InspectionDate" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema> I'd also note that there might be extra design considerations to help if there were to be a mapping to a redeclaration/non-polymorphic design (with local declarations as in ATG2's NDR) supported by a stylesheet say. Then we might want to help a transformation by deriving *every* element with a substitutionGroup headed by the previous version global element, even when extension wasn't required by the model. This would get all the information into each Schema rather than relying on more complex parsing (perhaps with XSLT 2.0) to get it from the imported Schema (I've no idea yet how this might be done without looking at it further but I reckon it should be possible). Then a UBL polymorphic Schema might be always readily transformed (with XSLT, say, or XQuery) into the ATG2 NDR equivalent for validation by both of the same instance. This might also remove the need for extra prefixes for common aggregate components. The above might be needed all the more so where there were further minor versions. It might give a more level structure for the design of imports and derivations in the second and subsequent minor versions (otherwise some derivations would be based on the previous version and others on the version before or the one before that). I'm not sure that all this can be achieved if there were to be minor versions with the same namespaces as the previous major version (if that is desirable). Perhaps it would require includes rather than imports. It would probably require more extensive rewriting of the NDRs. All the best Steve
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]