[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Creating Qualified Data Types - spreadsheet, EDIFIX and Schema
Tim, With all due respect, there have been problems with the quality of data in the Excel spreadsheets from the beginning of efforts to build UBL 2.0. Please, correct me if I'm wrong, but I also remember that Michael picked about 200 technical problems from the draft spreadsheets for UBL 1.0. To date, none of the issues are related to anything that is unique to EDIFIX. You wrote books about modeling and UBL. As such you are an expert and as a consultant you will easily understand the following conceptual issues: First, A. UBL adopted the ATG2 XSD schema for unqualified data types. B. UBL defines itself by following a modeling approach, which uses spreadsheets. C. UBL defines a informative set of model spreadsheets which have to be complete and have to include a spreadsheet for the unspecialized CCTS data types as UBL wants to use them. Otherwise UBL delivers an incomplete spreadsheet based model. Second, A. The ATG2 unqualified XSD schema CANNOT be auto generated from unqualified data types as of CCTS 2.01, because they are restricting unqualified data types as of CCTS 2.01. B. Qualified CCTS data types are based on the unqualified CCTS data types. If UBL members want to develop qualified CCTS data types, even in a spreadsheet, they have to know how the restrictive (compared with CCTS 2.01) unqualified data types for UBL/ATG2 look like. Otherwise, they could start to define qualified CCTS data types and to specify supplementary components, which do not appear in an ATG2 compliant XSD schema for an unqualified data type. As I recall you and others had very strong opinions about using spreadsheets and not other approaches presented to the TC that would minimize these problems. IMHO, it is time for everyone who feels so strongly about using spreadsheets as the master technique for UBL data to step up to the plate and help create correct spreadsheets that EDIFIX can import to create the UBL 2.0 data models. To create UBL data models and schema, EDIFIX needs spreadsheets that are conformant to ATG2 uDT, CCTS and UBL NDR. EDIFIX has no other special requirements. Best regards, Sylvia -----Original Message----- From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Friday, October 21, 2005 9:45 PM To: swebb@gefeg.com Cc: ubl@lists.oasis-open.org Subject: [ubl] Creating Qualified Data Types - spreadsheet, EDIFIX and Schema I am still confused by this. Maybe if i try to explain what i think is required and you can correct me. In UBL 1.0 we create spreadsheets for Core Components Types, Unqualified Data Types and Qualified Data Types (although we used the term Specialized instead of Qualified). I dont think that these were actually used by EDIFIX and the equivalent structures were hand built in the EDIFIX model. This is probably because we had already hand built the CCT, uDT and qDT schemas and all EDIFIX did was reference these when it created its schemas. In UBL 2.0, we are not using the hand crafted schemas for CCT and uDT because we are referencing those built by ATG2. So technically UBL needs no CCT or uDT spreadsheets and EDIFIX can do whatever it needs to to make the appropriate reference to the ATG2 schemas. We do not expect EDIFIX to create these schemas (unless it wants to) merely reference them. In UBL 2.0 we also need a new version of the qDT schema because it has to refine the ATG2 uDT types. It is up to UBL to define these qDTs (for our code list implementations). Again, we do not expect EDIFIX to create this schema (unless it wants to) merely reference the one we will hand build. The only reason we need spreadsheets for this is to provide consistent modeling artifacts at all three modeling stages. For the past three weeks we have been trying to get the structure and content of the qDT spreadsheet correct so EDIFIX is happy with it, and can create its equivalent model. My proposal is that GEFEG define exactly what EDIFIX expects for a qDT and we can provide a spreadsheet that does it. At the same time we need someone who feels able to, to take the ATG2 Unqualified Datatypes schema and make the necessary UBL Qualified Datatypes schema. Do you think this will work? Sylvia Webb wrote: >Tim, > >In response to your statement "it sound like from the minutes as though >we are attempting to reinvent what is already going on." What do you >suggest that we consider to prevent reinventing the wheel? > >Regards, >Sylvia >________________________________ > >From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] >Sent: Friday, October 21, 2005 2:19 AM >To: swebb@gefeg.com >Cc: jon.bosak@sun.com; ubl@lists.oasis-open.org >Subject: Re: [ubl] Minutes of Atlantic UBL TC call 19 October 2005 - >Qualified Data Types > > >i can understand why they would be different. the qDT we ae working is >based on the old UBL specilaizedDataType - but thats we have to go on >becasue (as you say) ATG2 dont use spreadsheets models (or anything but >schemas). > >would it be better if David could tell us how they are different, or >better still, described what the qDT spreadsheet needs to look like? >at present I fell we are grasping in the dark trying to guess what the >model we are aiming for looks like. > >it sound like from the minutes as though we are attempting to reinvent >what is already going on. > >Sylvia Webb wrote: > > Tim, > > When I imported the last qDT spreadsheet, I noticed some errors that > required further research before any comments could be made. David >Kruppke > completed that research this past Monday and determined that the uDT >and qDT > model types are different and the cause of the errors. > > Regards, > Sylvia > -----Original Message----- > From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] > Sent: Thursday, October 20, 2005 9:37 PM > To: jon.bosak@sun.com > Cc: ubl@lists.oasis-open.org > Subject: Re: [ubl] Minutes of Atlantic UBL TC call 19 October 2005 - > Qualified Data Types > > i am really confused by this discussion because for the past 3 weeks >we have > been trying to supply Sylvia with a QDT spreadsheet that loads into >EDIFIX. > > i understood we were donw to agreeing on the values in the data type >column. > so can someone explain what the difference between what Peter and I >have > been doing is from what you are asking for now? > > > jon.bosak@sun.com wrote: > > > > ACTION: JB to appeal to the list for volunteer(s) to develop > a QDT spreadsheet. > > > > > > > -- > regards > tim mcgrath > phone: +618 93352228 > postal: po box 1289 fremantle western australia 6160 > > DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business > Informatics and Web Services > >http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94 E > -22FF8CA5641F&ttype=2&tid=10476 > > > > >--------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in >OASIS > at: > >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > >--------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in >OASIS > at: > >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E -22FF8CA5641F&ttype=2&tid=10476 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]