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

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.

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