RE: [OAGI-CoreComponents] Re: [ubl-lcsc] Modified Schemas and Perl-Script

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Title: Message

Hello Garret,

 

that's correct, we should look that we will get one XML Schema of Core Component Types. I'm totally agree with you.

 

I can answer you following:

 

1.) The commonAttributes Attribute Group is not decided within the NDRSC yet. We said that we need some common attributes for every component. But we didn't decided the attributes of this attribute group. I made a proposal and you will find this proposal in the XML-Schema of Core Components. We can delete this group, so long we didn't decided the attributes itself.

 

2.) Now, it is not very clear, for which kind of types and/or terms we should do a definition within the XML schema. There are two possibilities: a.) we define the Core Component Types only or b.) we consider the Secondary Representation Terms, too. The advantage of a. is that we are considering the Core Component Types according the ebXML CCTS V1.9. But we can express the data type of many secondary representation terms by specific built-in data types (like date, time etc.). Therefore, I made the suggestion, that we define all representation terms within the basic schema. May be it will be better, if we changing the name of this schema than (From CoreComponentType.xsd into RepresentationTerm.xsd).

 

3.) ElectronicAddressType is a suggestion for a new Core Component Type, because we don't have a CCT for representing an URI as content component. I made this suggestion internally in UBL NDRSC and if we agree, we can refer this to the CC-Group.

 

4.) You will find in the last generated schemas new, UBL specific, temporary IDs. This is fully compliant to the ebXML CCTS Version 1.9. It says:  "Assign a Temporary Identifier to the new item in the form of a 6 digit alphanumeric string, chosen at the discretion of the user."

 

5.) We agreed that we do so much restrictions as possible. For example we using the specific built-in datatypes for representing the data-content. And additionally, we said, we should restricting code lists or identifier lists as far as possible. For example, we using UN/ECE Rec. 9 V.2002 only for representing the currency code of amount.  This will be much more easier for the users. Because, he they not searching and agreeing a specific version of code lists, before the exchanging their data.

 

I don't understand your another related topic. Could you explain this a little be more. Thank you.

 

If you still have some questions or comments, do not hestitate to contact me.

 

Kind regards,

 

    Gunther

 

 -----Original Message-----
From: Garret Minakawa [mailto:garret.minakawa@oracle.com]
Sent: Mittwoch, 15. Januar 2003 00:43
To: Stuhec, Gunther
Cc: 'Tim McGrath'; UBL-LCSC (ubl-lcsc@lists.oasis-open.org); OAGI-CoreComponentsWG
Subject: [OAGI-CoreComponents] Re: [ubl-lcsc] Modified Schemas and Perl-Script

Gunther,

I have still not given up on the idea of multiple standards organizations that are working on ebXML Core Components having one, shared XML Schema for Core Component Types.

However, in order for this to be possible, the shared file needs to strictly adhere to the rules and guidelines contained in CCTS v1.90.

After reviewing this latest version of CoreComponentTypes.xsd, I believe the following areas do not conform to CCTS v1.90.

1.  commonAttributes Attribute Group.  Perhaps this should exist in a UBL-specific layer that is applied to the Core Component Types schema.

2.  DateType, TimeType, PercentType, NameType.  I may be wrong about this, but I interpret the list in Table 8-1 of CCTS v1.90 as being very specific about approved Core Component Types.  Date, Time, Percent, and Name are valid Secondary Representation Terms but are not valid Core Component Types.  Use of Secondary Representation Terms are permitted for Data Types.

3.  ElectronicAddressType.  Not one of the approved Core Component Types.

4.  id values.  Again, I may be wrong about this but the id values (e.g. 000105, 000066) used in CoreComponentTypes.xsd appear to be taken from the Catalog of Core Components published in November, 2001 by the CCTS (or CCSD) team.  This document is not considered to be an official publication of CCTS or CCSD so UIDs in this document should not be considered part of CCTS v1.90.

5.  default values.  Use of default values for attributes in CoreComponentTypes.xsd may not apply universally and should be considered UBL-specific.  This is an issue if the intention is for multiple standards bodies to share a common XML Schema implementation of Core Component Types.

I would appreciate your comments and ideas about this.

Another related topic is UBL's position/use of Data Types as described in CCTS v1.90.  I don't believe UBL has defined any Data Types and was wondering how Data Types fit into the overall architecture for UBL.

If you have any questions about this, please let me know.

Regards,

garret
 

"Stuhec, Gunther" wrote:

 

Hello Tim,

you will find a zip-file as an attached file with the following files:
--> config_UBL.xml (configuration file for the Perl-Script)
--> CoreComponentTypes.xsd (modified schema of core component types)
--> EXXML.pl (Perl-Script itself)
--> ubl.bat (little batch file for call up the Perl-Script with all parameters)
--> UBL_Reusable_04.xls
--> UBL_Reusable_04.xsd

I made the following modifications:

CoreComponentTypes.xsd:
I added the secondary representation term "name" as an additional complexType.

UBL_Reusable_04.xls
--> I changed all representation terms into "name" from all BBIEs, which has the property term "name".
--> I fixed the "BBIE Contact. E-mail. Text" within the ASBIE "Contact. Details". It missed the occurence and the acronym "BBIE". I guess, this was the mistake of Contact.E-mail.

--> The ABIE "Foreign Exchange_ Contract. Details" or "Contract. Details" still missing. Because the ASBIE "ForeignExchangeContract" within the schema refers to the type "ForeignExchangeContract" and this does not exist.

EXXML.pl
--> the generation of the ccts-element within the annotation was wrong. I modified the perl-script and generated a new schema. You will find it as file UBL_Reusable_04.xsd. For my feeling, the annotations are OK, now.

Kind regards,

        Gunther

<<UBL_Library_0p4.zip>>
 

Yahoo! Groups Sponsor

ADVERTISEMENT

To 
unsubscribe from this group, send an email 
to:
OAGI-CoreComponents-unsubscribe@yahoogroups.com



Your 
use of Yahoo! Groups is subject to the Yahoo! Terms of Service.