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

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:] 
Sent: Mittwoch, 
15. Januar 2003 00:43
To: Stuhec, Gunther
Cc: 'Tim McGrath'; 
UBL-LCSC (); 
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:


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