[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SSC Report, 12 October 2004
SSC Report, 12 October 2004 The SSC discussed EDIFIX (EF) and the UBL development process this week. Below is a discussion summary. For complete details see the minutes posted at http://lists.oasis-open.org/archives/ubl-ssc/200410/msg00003.html. Attached diagrams show a) the overall process envisioned in these discussions, and b) a detail of the 'Design and Modeling' phase showing areas in yellow where EF would most be utilized. Regarding EF proposal: It was agreed that Sylvia will prepare a user agreement which outlines specific features of EF along with how it would be used, how it would be provided, and details on training and suport. In addition, the information below will either be covered in the proposal or provided separately. - Detail of what data is needed in a UBL submission for entry into EF. - Whether an .xsd or .csv output format could be implementable within the 1.1 timeframe. - A sample of the generic xml schema output format to be sent to Stephen. - A query posted to the ubl-dev list to ask what types of formats are in frequent use as intermediary interchange format. - A description of the origin of the content of the EF schemas: ss models, ndr rules, code lists, wizard parameters, other external standards, etc. - A review the CM Guidelines and statement as to whether EF supports them and how. - Description of which parts of the UBL ss model EF uses (or ignores). How EDIFIX fits into overall process: - EF would mainly be used to create schemas. - EF may also be used to generate the CCTS data models. GEFEG proposes that EF can be used for even more, but this needs further discussion. - A prerequisite to using EF is the alignment of the current EF ss/schema output to the current spreadsheets. EDIFIX input and output formats: - EF will take as input a spreadsheet in .xls format (generated either by Excel or OO), either the UBL format or the TBG17 format. so the following transformations will be supported: UBL ss -> UBL ss UBL ss -> tbg17 ss TBG17 ss -> UBL ss TBG17 ss -> TBG17 ss Additional input/output formats: - UBL needs to decide on what transformation format is best for the TC. - GEFEG will assess the business cases for support of additional formats. - UBL is not currently requesting support for XMI format output for UBL, nor are we currently requesting native OO support. - UBL needs to know exactly what EF pulls from the spreadsheets and what parts are imported from elsewhere, as well as what parts are currently hard-coded values in EF or generated by some other mechanism in EF. - UBL may need to make minor changes to the format of the spreadsheet models at times (eg adding columns). NDRs: - There needs to be an exhaustive review of the compliance of the schema to the ndrs. This should be done at the same time as the preliminary testing for consistency in output between the ss and EF is done (before we begin using EF). - EF would make it possible for those working on the NDRs to directly see the rsults of their rules on the schema, a great aid to rules development. Code List support: - Tony is proposing xml as a source and transmission format for code lists. EF already has functionality to allow one to specify which codes in the list you use but the methodology still needs to be specified. - Code lists have not been fleshed out yet. This is a big concern for EF use. We need agreement/decision on code list methodology. Maintenance: - UBL needs to maintain the existing ss format to a large degree for existing users and contributors such as the localization SCs. - It will be more difficult to change the tool to meet UBL practice (becuase EF is a product with many other user groups) so, practically speaking we will have to modify some of our input practices to accomodate the tool. Development environment: - EDIFIX is not a document management system, nor a source control system and not based on a client-server architecture. Each instance of EF contains the entire model, on the local file system, so each person working on the model has their own version. - Merging changes will have to be done manually or through a proper source control system. We can generate the required outputs from EF and then distribute them to UBL developers or users via other mechanisms: email, kavi, a server, etc. We will continue to need a gatekeeper to manage changes with emphasis on an accurate change log. - The UBL change intake process should look at ways of versioning UBL that will not interfere with bringing in new changes to the model. - EF runs natively only on MS Windows. This may limit who can do development. It's possible it can be run on other OS's with an emulator. Training: - Training to be detailed further in the proposal. - Training will include some ubl-specific material and can be used to further explore some of the thoughts expressed above. EF Reader: - The Reader provides several different views (eg. tree structure) of the standard in html, pdf, rtf, and for schemas, samples. The Reader is pre-bundled with a specific version of any standard. It is a valuable tool for business users to view progress/direction. Frequency of possible updates is yet to be determined, possibly monthly. UML: - EF will not be used to produce the UML diagrams as released with 1.0. Customization methodology support: - UBL 1.1 will require EF to support the CM guidelines/methodology. Resources: - Other UBL members (not GEFEG resources) will be using EF to do UBL development since GEFEG resources are already taxed providing tool development. - UBL is already resource-constrained and this process will take more resources. - GEFEG needs to know what the work requirements are going to be for EF (features) for 1.1 in order to allocate resources appropriately. - From a commercial perspective, GEFEG is committed to supporting UBL.