[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] AW: UBL 1.0 Beta - Data type issues
Dear all, A few weeks ago, Anne sent an email to an UBL list which gave a download link where the UBL 1.0 Beta version can be viewed as a set of UML data models or as a set of schema objects. A copy of this email is attached below. I'd like to distribute the free UBL 1.0 Reader in January, because of I think it makes the UBL models and schemas easier understandable for users. But I'd prefer to get any echo from the experts whether the data whether are OK or not. These views illustrate well the importance of the systematic CCTS naming of the objects inherited consistently within the data models and across the schemas. In addition these views also illustrate a significant potential problem: a modeller (in this case me!) can very freely decide on what modelling rules to apply. Example 1: I decided to build two views of the same models: a CoreComponentView and a UBL object name view. Example 2: I built one model object Datatype for each different entry in the Data Type/Representation Term column of the UBL spreadsheets and restricted the used CoreComponentTypes just once. But is would be also possible to refer to the CoreComponentTypes directly and not to restrict them. Result: two different data models. This raises the following questions for me: a) is it OK, that UBL data models, which are not expressed in a spreadsheet, can adopt different modelling approaches? b) does the UBL TC feel, my UBL representation is OK? c) If not: how should the UML representation of UBL data look? Currently, the normative spreadsheets for the documents and the reusable type structures are the only official instantiation of the UBL data model available. These spreadsheets contain no direct links or explanation on how to handle data types and codelists at the data model level. The models are actually incomplete and consequently there is no way to derive UBL schemas directly and automatically from the spreadsheets alone, i.e. neither a logical way nor a technical way. It can probably be assumed that some future UBL users will want to develop/evolve their specific requirements from the UBL data models and then they will probably be asking similar questions. I think that it is very important to be very clear whether it is the schemas or the data models which are the master from which extensions and customisations should be developed. If the schemas are considered to be both the maintenance and publication master data, then the spreadsheets should become just a derivative of the schemas and their position in any explanatory diagrams should be changed accordingly (i.e. to mark them clearly as XSD derived). If not, then I suggest that the UBL NDRs should be used and extended, if necessary, to rule how to go from model to schema. This latter approach would require that all necessary data including data types, codelists and their relationships must be stored in the data models. To which TC(s) shall I address these issues? thanks Michael Dill Hi Michael, I apologize that I am not as quick as you'd like in getting your information to the team, but we usually only meet once a week, so it usually takes a few days to get back to people on things. I just sent your information to the TTSC (and added you to the alias). We are in the process of developing a requiements/scope document, which I have attached, and you may feel free to add your comments as well to the list. This was sent out last week. I am putting your tool on the agenda for next week, but some may reply earlier as I sent them your email showing interest in feedback. In terms of ccts, both Garret and Gunther have been closely working with us to ensure CCTS compliance. As you heard, I'm sure, we have a bit of a problem with CCTS changing. But for the Beta release we believe we achieved CCTS 2.0 compliance. I think that may be stated in the documents somewhere. I'll see if I can find where. Now, since the release Sue Probert has told us that there are a few more changes to CCTS. But she said they were small and we hope they will be done in time for us to put them into the final release. This means they will have to be done before the end of December. So if you can help in this regard, please do! :) We are doing everything we can to remain in compliance! I'm not sure what you mean when you say " + re-use of reusables ". I believe reusables are CCTS compliant as well. They are part of the UBL data model. Perhaps I misunderstand this part of the question. -Anne dill wrote: >-----Ursprüngliche Nachricht----- >Von: dill [mailto:dill@gefeg.com] >Gesendet: Montag, 1. Dezember 2003 22:03 >An: anne.hendry@sun.com >Betreff: UBL Reader > > >Anne, >please find enclosed the download for the UBL reader. If you feel, it's OK, >then I'd be glad to get any feedback. >I think, it helps really for the further UBL development. For member of the >TC the UBL Reader and Editor is free, for the direct Standard work. >Thank you >Michael Dill > >Dear All, > >GEFEG has built a version of its EDIFIX schema and data model reader for the >Universal Business Language (UBL). The GEFEG UBL Reader offers an easy >access to the UBL schemas and data models through its unique combination of >tree structures, easy navigation and clearly arranged background >information. >This UBL Reader containing both the UBL 1.0 Beta data models and schemas is >available as afree of charge download from the GEFEG.COM web-site. > >The link for downloading the UBL Reader is: >http://www.gefeg.com/en/edifix/reader-ubl.html >!!! Please do not forget to choose the 'UBL Reader' from the choice of >reader list box !!! > >Choose to download the self-extracting .exe and then run this to unzip and >automatically install the reader software. > >During installation you will be asked for licence information. Please copy >and paste the following details into the requested fields: > >Name: UBL Reader - Free Of Charge >Licence: FX-271103-20003-1620 >Key: H1K16-R1111-KN1BL-ZF > >As UBL is UN/CEFACT Core Component compliant, the GEFEG UBL Reader offers >TWO Views of the data models! One set of UBL data models presents the object >names as UN/CEFACT Core Component Directory Entry Names whilst the other >presents the UBL object names. > >Both sets of data models as well as the set of schemas demonstrate the >inheritance of the Directory Entry Names and other documentation remarks. >This inbuilt inheritance avoids rekeying and thereby provides a redundancy >free environment. > >If you have any interest in having a free GEFEG EDIFIX UBL Editor to assist >with the standardisation work of the OASIS UBL TC including spreadsheet >export and import of the models, automatic schema derivation from the >document models etc., then please send me an email. > >Please have a look at the data models. I'd be glad if there were any >comments about them which could help to improve the data. > >We hope that you enjoy these views of all the hard work of the past two >years. > >Best Regards, >Michael Dill > > > >Further Features of the UBL Reader >========================== >Provision of clear hierarchical tree structures, enriched with comments and >descriptions Availability of all information relating to an element directly >in the tree at the element position Opening and closing of sub-trees Ms >explorer-like backward and forward navigation Viewing of a structure diagram >for a message, or parts of a message Viewing of a collapsible and expandable >UML class diagram of a data model, or parts of a model > > >Notes for EDIFIX users: >======================= >If you have already any version of EDIFIX installed on your computer, then, >please: > >1. make sure that all EF sessions are closed during installation of the UBL >reader 2. choose a directory other than the normal EDIFIX directory to store >the UBL reader program files (During installation EDIFIX will ask you where >you wish to store these program files) 3. choose a directory other than the >normal EDIFIX directory to store the UBL reader data files (During >installation EDIFIX will ask you where you wish to store these data files > > >
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.
-- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]