OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ssc message

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


Subject: Minutes of SSC Call 17th March 2005


Minutes of UBL Software SC Call 17th March 2005
—----------------------------------------------------------

Those present:

David Kruppke
Tony Coates
Stephen Green

Apologies:

Anne Hendry
Sylvia Webb


Reports from other teams:

Tony still yet to hear from Marty regarding codelists

Main Topic:

The meeting focussed on further discussion of the
Schema design and generation for UBL 1.1

Derivation
------------

It was agreed that derivation by extension was feasible
for 1.1, with imports of 1.0 Schemas but that there 
should be a redeclaration of every element under the new
1.1 namespace and possibly of every global complexType
with scope to extend by XSD derivation the redeclared
types where the spreadsheet models indicated to do
so.

To demonstrate that certain aspects of XSD derivation were
not possible for 1.1 some simple examples would be useful.
This would help with discussions and review by the TC/NDR 
team, etc.

[see below for a view of what might be feasible in 1.1 Schemas]

Other Business:

NDR CT20 - property terms and complexTypes
----------------------------------------------------------

CTD20 seems to require changes to names of complexTypes
so it is questionable whether it adequately preserves backwards
compatibility (it could be said that changing type names is
OK for instances in 1.1 but it seems to be a grey area and we
thought this kind of change best avoided). Therefore it was
agreed that David need not implement this rule until there
was more assurance from the TC/NDR team that it was
demonstrably safe to do so.


Next Meeting:

The availability of members means we plane to have a meeting 
next week despite its closeness to the holidays.





Further Details of Discussion of UBL 1.1 Schema Design and Use of XSD Derivation
-----------------------------------------------------------------------------------------------------

A simple example of the requirements would be the addition of an InspectionDate
BBIE to both an Invoice and an InvoiceLine - the former in the 1.1 Invoice Document
Schema and the latter in the 1.1 Common Aggregates Schema with the declaration
of the InspectionDate BBIE itself in the 1.1 Common Basic Schema.

The addition to the 1.1 CAC Schema could something look like this:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.1" 
xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0" 
xmlns:cac1.0="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0" 
xmlns:cbc1.0="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" 
xmlns:cbc="CommonBasicComponents-1.1" 
xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatypes-1.0" 
targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.1" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified" 
version="1.0">
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0" schemaLocation="../../xsdrt/common/UBL-CoreComponentParameters-1.0.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0" schemaLocation="../../xsdrt/common/UBL-CommonAggregateComponents-1.0.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" schemaLocation="../../xsdrt/common/UBL-CommonBasicComponents-1.0.xsd"/>
	<xsd:import namespace="CommonBasicComponents-1.1" schemaLocation="CommonBasicComponents-1.1.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatypes-1.0" schemaLocation="../../xsdrt/common/UBL-UnspecializedDatatypes-1.0.xsd"/>


...    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:schema>

Note that because *every* BIE gets the 1.1 namespace, the namespace for 1.0 isn't then needed in instances, so they might as well
all have the same prefixes as 1.0 (but the prefixes would have to be different for the 1.0 namespaces within the Schemas, where they 
are imported.


The 1.1 Document Schema would then look something like this:


?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:in1.0="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0" 
xmlns:cac1.0="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0" 
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.1" 
xmlns:cbc1.0="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" 
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.1" 
xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatypes-1.0" 
xmlns:cur="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0" 
xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.1" 
targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.1" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0">
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0" schemaLocation="../../xsdrt/common/UBL-CommonAggregateComponents-1.0.xsd"/>
	<xsd:import namespace="CommonAggregateComponents-1.1" schemaLocation="../common/CommonAggregateComponents-1.1.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" schemaLocation="../../xsdrt/common/UBL-CommonBasicComponents-1.0.xsd"/>
	<xsd:import namespace="CommonBasicComponents-1.1" schemaLocation="../common/CommonBasicComponents-1.1.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:UnspecializedDatatypes-1.0" schemaLocation="../../xsdrt/common/UBL-UnspecializedDatatypes-1.0.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0" schemaLocation="../../xsdrt/maindoc/UBL-Invoice-1.0.xsd"/>
	<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0" schemaLocation="../../xsdrt/codelist/UBL-CodeList-CurrencyCode-1.0.xsd"/>
	<xsd:element name="Invoice" type="InvoiceType"/>
	<xsd:complexType name="InvoiceType">
		<xsd:sequence>
			<xsd:element name="ID" type="udt:IdentifierType"/>
			<xsd:element ref="cbc:CopyIndicator" minOccurs="0"/>
			<xsd:element name="GUID" type="udt:IdentifierType" minOccurs="0"/>
			<xsd:element ref="cbc:IssueDate"/>
			<xsd:element name="InvoiceTypeCode" type="udt:CodeType" minOccurs="0"/>
			<xsd:element ref="cbc:Note" minOccurs="0"/>
			<xsd:element ref="TaxPointDate" minOccurs="0"/>
			<xsd:element name="InvoiceCurrencyCode" type="cur:CurrencyCodeType" minOccurs="0"/>
			<xsd:element name="TaxCurrencyCode" type="cur:CurrencyCodeType" minOccurs="0"/>
			<xsd:element name="PricingCurrencyCode" type="cur:CurrencyCodeType" minOccurs="0"/>
			<xsd:element ref="LineItemCountNumeric" minOccurs="0"/>
			<xsd:element ref="cac:OrderReference" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="DespatchDocumentReference" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="ReceiptDocumentReference" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="AdditionalDocumentReference" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="cac:BuyerParty"/>
			<xsd:element ref="cac:SellerParty"/>
			<xsd:element ref="cac:Delivery" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="cac:PaymentMeans" minOccurs="0"/>
			<xsd:element ref="cac:PaymentTerms" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="cac:AllowanceCharge" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="cac:ExchangeRate" minOccurs="0"/>
			<xsd:element ref="cac:TaxTotal" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element ref="cac:LegalTotal"/>
			<xsd:element ref="cac:InvoiceLine"/>
			<xsd:element ref="cbc:InspectionDate" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="AdditionalDocumentReference" type="cac1.0:DocumentReferenceType"/><!-- the reuse of the 1.0 type is a possibility here -->
	<xsd:element name="DespatchDocumentReference" type="cac1.0:DocumentReferenceType"/><!-- the reuse of the 1.0 type is a possibility here -->
	<xsd:element name="LineItemCountNumeric" type="in1.0:LineItemCountNumericType"/><!-- the reuse of the 1.0 type is a possibility here -->
	<xsd:element name="ReceiptDocumentReference" type="cac1.0:DocumentReferenceType"/><!-- the reuse of the 1.0 type is a possibility here -->
	<xsd:element name="TaxPointDate" type="in1.0:TaxPointDateType"/><!-- the reuse of the 1.0 type is a possibility here -->
</xsd:schema>

Note that again, every element is redeclared but locally declared types could be reused from 1.0 imports.



An instance would then look like this:


<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.1" 
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.1"  
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.1
../xsd-prototype-1.1/maindoc/Invoice-1.1.xsd">
	<ID>12345</ID>
	<cbc:IssueDate>1967-08-13</cbc:IssueDate>
	<cac:BuyerParty><cac:BuyerAssignedAccountID>101</cac:BuyerAssignedAccountID></cac:BuyerParty>
	<cac:SellerParty><cac:BuyerAssignedAccountID>122</cac:BuyerAssignedAccountID></cac:SellerParty>
	<cac:LegalTotal>
		<cbc:TaxInclusiveTotalAmount amountCurrencyID="AED">1.00</cbc:TaxInclusiveTotalAmount>
	</cac:LegalTotal>
	<cac:InvoiceLine>
		<cac:ID>1</cac:ID>
		<cbc:LineExtensionAmount amountCurrencyID="AED">1.00</cbc:LineExtensionAmount>
		<cac1.1:Item><cac1.1:BasePrice>
			<cbc:PriceAmount amountCurrencyID="AED">1.00</cbc:PriceAmount>
		</cac:BasePrice></cac:Item>
		<cbc:InspectionDate>2005-01-01</cbc:InspectionDate>
	</cac:InvoiceLine>
               <cbc:InspectionDate>2005-01-01</cbc:InspectionDate>
</Invoice>

Note that it is virtually identical to a 1.1 instance, except for the added 
InspectionDate and the namespaces

This was the kind of design thought most appropriate in this meeting


Spreadsheet Considerations
---------------------------------


It was noted that the TC Pacific call asked for the 1.1 spreadsheet design to be 
undertaken by the SSC.

This spreasheets would have to indicate the intention that an XSD extension be 
used where appropriate.

It seems likely, from the Pacific TC call minutes, that this would typically be where there
is the need for an extension without a new, qualified outer 'container' ABIE e.g.
we need to add a new Contact ASBIE to Delivery and we could avoid the need for 
a new xxxDelivery (not backwards compatible) by using XSD extension. This would
have to be made clear to the generator in the spreadsheet along with appropriate
version flag. 

The SSC will need to look at this in forthcoming meetings.




 



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