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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: RE: [ubl-lcsc] RE: [ubl-ndrsc] XML Schema with Global Defined Elements - URGENT support call

Title: Message
(Tim: the "tim's draft" schema defines no BBIE's -- notice it's 374 KB whereas xxReusable.xsd is 438KB.  In what follows I'm referring to xxReusable.xsd)
A few points inline...
-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Wednesday, January 15, 2003 9:17 PM
To: Burcham, Bill
Cc: 'Stuhec, Gunther'; UBL-LCSC (ubl-lcsc@lists.oasis-open.org); UBL-NDRSC (ubl-ndrsc@lists.oasis-open.org)
Subject: Re: [ubl-lcsc] RE: [ubl-ndrsc] XML Schema with Global Defined Elements - URGENT support call

i need some urgent technical support on interpretting these changes...

Currently we have things like...
    <xsd:complexType name="AccountsContactDetailsType" id="UBL000001">
                <ccts:ABIE dictionaryEntryName="Accounts_ Contact. Details" definition="information that identifies the Seller's contact person or department on Accounts matters, together with information about how they can be contacted." qualifierTermObjectClassTerm="Accounts" objectClassTerm="Contact" propertyTerm="Details" representationTerm="Details"/>
            <xsd:element ref="ID" id="UBL000002">
                        <ccts:BBIE dictionaryEntryName="Accounts_ Contact. Identifier" definition="identifies the department or employee by a unique identity other than their name when given as a contact." qualifierTermObjectClassTerm="Accounts" objectClassTerm="Contact" propertyTerm="Identification" representationTerm="Identifier"/>
The problem I am getting is with the statement...
            <xsd:element ref="ID" id="UBL000002">

- when i use the XML Spy Schema view it links ref="ID" with the first ID it finds (in this case Transport Equipment Seal.Identifier)  and displays that definition.  The same applies when we use ref="Name" and so forth. obviously, this is common throughout the schemas. 
If XML Spy is doing that then it's a bug since the element declaration inside TransportEquipmentSealDetailsType is in a scope not reachable from  AccountsContactDetailsType.  My XML Spy (version 5) does not have that problem.  Also, I verified that there is only one element declaration named "ID" at the top level so we're ok there.
On a separate note, I see a few problems around our unique identifiers. The tag name (qname) "ccts:BBIE" used in the annotation of elements representing Basic Business Information Entity Properties is misleading.  In the example above, the element declaration (referencing the ID element declaration) does not represent a BBIE, rather it represents a Basic Business Information Entity Property.  As further evidence of the problem, notice that we use the same documentation tag (ccts:BBIE) for actual BBIEs (e.g. ActionCode).  So we're using that tag both to document actual BBIEs and to document _properties_ that _reference_ BBIEs.
We should create a new element in CCTS.xsd called BBIEP and use that element to hold documentation on the BBIEP elements.
While we're at it we ought to rationalize the acronym for Association Business Information Entity Properties as well, from ASBIE to ABIEP both in the spreadsheet and in CCTS.xsd.
This (minor) problem prompted me to take a peek at the UBL identifiers we're generating.  Some things look right  a) we're generating a UBL identifier for each complex type (representing an ABIE) b) we're assigning the same UBL id to the element that references that type, c) we're generating a (different) UBL identifier for each (local) element declaration (within each complex type).  The latter correspond to the BBIEPs and ABIEPs from the previous paragraph.  That's all good.
But there are some problems around the unique identifiers for BBIEPs.  Here's a summary:
CCTs -- these look good.  Are these numbers assigned by CEFACT? (defined in CoreComponentTypes.xsd)
ABIEs -- correct - manifested as id attrs on complex types and global elements in the UBL generated schemas.  For example BuyerContact with UBL id attr = UBL000078
BBIEs -- correct -- see e.g. ActionCode, it's got an id attr = UBL000546
BBIEPs -- PROBLEM -- the BBIEP itself needs a UBL identifier whereas in the current schema, every BBIEP referencing a particular BBIE has that BBIE's id (rather than its own id).  For instance BBIEP Sales Conditions. Action. Code " which references BBIE ActionCode, has a UBL id attr = UBL000546 (problem is that this is the same as the UBL id for ActionCode)
ABIEPs -- correct -- each ABIEP (each local element referencing a global element representing an ABIE) has a different UBL identifier (captured in the id attr).  See for example ABIEP " Buyer_ Party. Buyer_ Contact " with UBL id attr = UBL000095 (note that this (correctly) differs from the UBL id for BuyerContract)
That's all for this morning.  Good night Tim.
Is this, as I suspect, an XML Spy feature ? - if so it makes reading these things pretty difficult for our audience, if not then how does Schema resolve these references (when we have so many with the same name)?

Burcham, Bill wrote:
Great work Gunther.  And fast!  I see (XML Spy 5 sees) these bugs in the schema:
Element ForeignExchangeContract is undefined (ref'd from ExchangeRateDetailsType)
I pondered and investigated why your scripts failed to stumble on the collisions I had predicted (previous post).  I had been looking solely at the property terms and qualifiers and not appending the representation terms.  Doing so disambiguates all the ambiguous cases I had uncovered.  Makes sense to me at least.
to point (a) below: I'd opt for putting the documentation/annotation with the type rather than the element
to point (b) below.  Yes it is possible.  And in fact your schemas (e.g. UBL_Reusable_05.xsd) has annotations on the local elements.
I don't understand (c).  and (d) is a genuine collision -- LCSC -- can you repair to your satisfaction?
Also, putting on my XML technologist hat -- is anyone else uncomfortable with all the noise in our our complex type names... isn't FooDetailsType a bit much?  FooType was bad enough!  (recall XSD has different namespaces for elements and types -- but I digress).
-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
Sent: Wednesday, January 15, 2003 4:34 PM
To: UBL-LCSC (ubl-lcsc@lists.oasis-open.org); UBL-NDRSC (ubl-ndrsc@lists.oasis-open.org)
Subject: [ubl-ndrsc] XML Schema with Global Defined Elements.

Hello all,

I changed my Perl-Script now according the NDRSC definitions of Burlington. It generates all BIEs as global defined elements now. You'll find the complete package as an attached zip file.

Due to problems with Tims Excel spreadsheet "UBL_Library_0p70_Reusable.xls", I still used the Excel spreadsheet "UBL_Reusable_04.xls". I renamed it in ""UBL_Reusable_05.xls", now.

There are still some problems with global defined elements:
a.) Where I put the annotation of all BIEs? Within the complexType, or within each global defined element?

b.) Is it possible to put an annotation within an defined element, which refers to a global defined element?

c.) There does not existing an global defined annotation of generic (reusable) BBIEs, which are defined as global defined elements. My perl script taking always the annotations from the last defined BBIE.

d.) There existing the tag name "PaymentTerms" twice. One for "Payment Terms. Details" and the other for "Payment Terms. Text". Both is correct, because we decided that we can eliminate the representation terms "Text" and "Details". I changed the "PaymentTerms" of "Payment Terms. Text" into "PaymentTermsPaymentTerms". But this looks not very nice. I guess, we will get this problem very often.

Kind regards,



tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 

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

Powered by eList eXpress LLC