[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU 9 MAY - 13 MAY 2005
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]