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] 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>>
 

Attachment: garret.minakawa.vcf
Description: Card for Garret Minakawa



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


Powered by eList eXpress LLC