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

1. I'd be aiming for something like this in the document schema:

<!-- ===== 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:cbc2-0="CommonBasicComponents-2.0" targetNamespace="Invoice-2.0"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="2.0-prototype-ver-sdg-4">
<!-- ===== Imports ===== -->
<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"/>
<!-- ===== Type Definitions ===== -->
<!-- ===== 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="cbc2-0: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="cbc2-0:LineItemCountNumeric" minOccurs="0"/>
<xsd:element ref="cac2-0:OrderReference" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:DespatchDocumentReference" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="cac2-0:ReceiptDocumentReference" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="cac2-0: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>

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.

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.

2. I'd think an idea worth considering would be to have a document-specific
module but with another 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

<xsd:complexType name="OrderLineType">
<xsd:sequence>
<xsd:element ref="cbc2-0:SubstitutionStatusCode" minOccurs="0"/>
<xsd:element ref="cbc2-0:Note" minOccurs="0"/>
<xsd:element ref="LineItem"/>
<xsd:element ref="SellerProposedSubstituteLineItem" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="SellerSubstitutedLineItem" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="BuyerProposedSubstituteLineItem" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

could then be restricted to something like

<xsd:complexType name="OrderLineType">
<xsd:complexContent>
<xsd:extension base="cac2-0:OrderLineType">
<xsd:sequence>
<xsd:element ref="cbc2-0:Note" minOccurs="0"/>
<xsd:element ref="cac2-0:LineItem"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

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

I guess this would be too different for 2.0 perhaps but it
might help to think of it now prevent this being ruled out
later.

The problem I've labelled 1. above does, however, for
all I can tell at present, need solving in the next release.

I'd like to do more work on this though to see exactly
how the options work - or I'd be very greatful if someone
else would check it out and provide the findings as I have done.

All the best

Steve




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




> Unfortunately in this situation where we need another
> namespace, the NDR prevents use of an internal schema
> module:
>
> "[SSM6] All UBL internal schema modules MUST be in the same
> namespace as their corresponding document schema."

And why do you need another namespace other than either the document or
common reusable?

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php