Re: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU 9 MAY - 13 MAY 2005

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Mark

Greetings and apologies:
I went away to check the problems I'd been getting
with document schemas and their elements and
namespaces and (still learning here) I couldn't
replicate the problem. Instead I found a way to
declare everything as necessary. I've attached a new
prototype demonstrating this just in case problems
reemerge later.

I haven't tried the proposed inclusion of core
components but I hope this design I have here
(though the polymorphic aspects have yet to be
debated fully in the NDR team) could be a good basis
for looking at that. It makes sense to me to use
derivation to base all BIEs on CCs declared in a
core module. It would take some time to prove or
disprove so I wonder how it would fit with our
schedule (I had been under the impression, perhaps
wrongly, that we had to complete the NDR decisions
by 1st June but it has recently been appearing in
schedules as 1st July).

Still, I'd be eager to trial a schema design for
CC incorporation quite soon to get a better
picture of where we are at. Perhaps others would do
the same and share their findings with examples or
prototypes.

All the best and sorry to mislead on the namespace thing.
(I really had been getting problems on this but maybe it
was due to caching problems or something).

Stephen Green

PS
By the way this is how the Invoice schema looks (and this works):

<!-- ===== xsd:schema Element With Namespaces Declarations ===== -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns="Invoice-2.0"
xmlns:cac2-0="CommonAggregateComponents-2.0"
xmlns:udt="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypeSchemaModule:
1.1.A"
xmlns:cbc2-0="CommonBasicComponents-2.0"
targetNamespace="Invoice-2.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2.0-prototype-ver-sdg-4">
<!-- ===== Imports ===== -->
<xsd:import
namespace="urn:un:unece:uncefact:data:draft:UnqualifiedDataTypeSchemaModule:
1.1.A" schemaLocation="../common/UnqualifiedDataType.xsd"/>
<xsd:import namespace="CommonAggregateComponents-2.0"
schemaLocation="../common/CommonAggregateComponents-2.0.xsd"/>
<xsd:import namespace="CommonBasicComponents-2.0"
schemaLocation="../common/CommonBasicComponents-2.0.xsd"/>
<!-- ===== Root Element ===== -->
<xsd:element name="Invoice" type="InvoiceType"/>
<!-- ===== Element Declarations ===== -->
<xsd:element name="AdditionalDocumentReference"
type="cac2-0:DocumentReferenceType"/>
<xsd:element name="DespatchDocumentReference"
type="cac2-0:DocumentReferenceType"/>
<xsd:element name="LineItemCountNumeric" type="LineItemCountNumericType"/>
<xsd:element name="ReceiptDocumentReference"
type="cac2-0:DocumentReferenceType"/>
<xsd:element name="TaxPointDate" type="TaxPointDateType"/>
<!-- ===== Type Definitions ===== -->
<xsd:complexType name="LineItemCountNumericType">
<xsd:simpleContent>
<xsd:extension base="udt:NumericType"/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="TaxPointDateType">
<xsd:simpleContent>
<xsd:extension base="udt:DateType"/>
</xsd:simpleContent>
</xsd:complexType>
<!-- ===== Aggregate Business Information Entity Type Definitions ===== -->
<xsd:complexType name="InvoiceType">
<xsd:sequence>
<xsd:element ref="cbc2-0:ID"/>
<xsd:element ref="cbc2-0:CopyIndicator" minOccurs="0"/>
<xsd:element ref="cbc2-0:GUID" minOccurs="0"/>
<xsd:element ref="cbc2-0:IssueDate"/>
<xsd:element ref="cbc2-0:InvoiceTypeCode" minOccurs="0"/>
<xsd:element ref="cbc2-0:Note" minOccurs="0"/>
<xsd:element ref="TaxPointDate" minOccurs="0"/>
<xsd:element ref="cbc2-0:InvoiceCurrencyCode" minOccurs="0"/>
<xsd:element ref="cbc2-0:TaxCurrencyCode" minOccurs="0"/>
<xsd:element ref="cbc2-0:PricingCurrencyCode" minOccurs="0"/>
<xsd:element ref="LineItemCountNumeric" minOccurs="0"/>
<xsd:element ref="cac2-0: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="cac2-0:BuyerParty"/>
<xsd:element ref="cac2-0:SellerParty"/>
<xsd:element ref="cac2-0:Delivery" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:PaymentMeans" minOccurs="0"/>
<xsd:element ref="cac2-0:PaymentTerms" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:AllowanceCharge" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:ExchangeRate" minOccurs="0"/>
<xsd:element ref="cac2-0:TaxTotal" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:LegalTotal"/>
<xsd:element ref="cac2-0:InvoiceLine" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>





----- Original Message ----- 
From: <MCRAWFORD@lmi.org>
To: <stephen_green@seventhproject.co.uk>; <ubl@lists.oasis-open.org>
Sent: Wednesday, May 18, 2005 4:04 PM
Subject: RE: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN
HANGZHOU 9 MAY - 13 MAY 2005




> This doesn't have any document specific BIEs and I can
> appreciate your point made earlier that there may be a
> requirement to have such.
>
> Having any document specific BIEs causes problems similar to
> those which required all Codes and Identifiers to be global -
> if the BIEs have the same namespace as the document - or so
> it seems from the work I've been doing with prototyping
> designs and checking their implications.

Could you please identify the problems

> So if we do need (I admit I can't see why very clearly) any
> document-specific BIEs then I think we'd possibly need an
> external schema module for them.

I guess I need to see the problems first before I could agree with this
assumption
>
> 2. I'd think an idea worth considering would be to have a
> document-specific module but with another namespace.

That is the part I don't yet understand - why a different namespace

>I'm thinking that in future it might be a suitable place to
> derive more suitable document specific types from common or
> core types so that, for example, an OrderLine in an Order
> doesn't have to include all the ASBIEs which are really there
> just for use in the OrderResponse

You just hit the nail on the head as to why we need Core Components.
With a core component of Line and BIEs of Order_Line and
OrderResponse_Line, you can segment the ASBIEs.

> This would cut down a lot on the overbloating of documents
> (one of the problems the SBS incidentally helps to solve).

The bloating and conflicts of the library are caused because we have
tried to use BIEs in a way that was never intended - as the CC and BIE
together.  As a result, the BIE is both a conceptual data model and a
physical data model.  CCs are intended to be the kitchen sink that never
ever get used for any purpose other than as a harmonization tool.  BIEs
are supposed to be specific assemblies for specific contexts in specific
exchanges - qualified and customized through restriction from the
conceptual CC.

Mark

xsd-derivation-prototype-ver-sdg-5.zzz