[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of UBL Atlantic Call 13 October 2004
Dear all please find below an account of today's Atlantic call. Regards Mavis ------------------- 1. Roll Call and welcome by Mavis the moderator. Attendees: Mavis Cournane Jon Bosak Marion Royal Jessica Glace Anne Hendry Tony Coates Sylvia Webb Paul Thorpe Marty Burns 2. EDIFIX DISCUSSION From a single data model the tool would create spreadsheets and schema. These could be compared against other spreadsheets that would be created for QA purposes. The spreadsheets would be imported into EDIFIX and it would use the current UBL spreadsheet template for this purpose. The TBG17 template is also supported. There would need to be an alignment between the data in the spreadsheets and what is needed to create consistent output. This alignment process would need to be discussed at the next face to face. AH: We want to keep the spreadsheets as our modeling format. JB: The burden of compliance would be on the submitter. They would need to submit in the agreed UBL template format. MB: In accepting submissions it is important to compare the input with the EDIFIX output. JB: We will need to open up the EDIFIX black box to understand how it works in order to get an understanding of what alignment will be needed. We should view this for now just in the context of 1.1 as we are constrained with input spreadsheets as there is a mechanism then set up for digesting these things. There are gating items: 1. We will have some work to make sure that the spreadsheet output aligns with our spreadsheet input. 2. With regard to code list spec, there are some aspects of this that need to be nailed down so that the tool handles code lists correctly. MB: Going to a model from XML is not a major issue for the tool. If you kept your data model in XML and rendered the schemas based on the data model, you could write an XSLT script to do the schemas. JB: Moving to the registry information model is something we would want to look at beyond 1.1. I am not clear given the fact that the schemas we put out are representations of our data model, I am not sure about the distinction. Are these linearised and is GEFEG more complex? The model that GEFEG is maintaining is something like the data model we have before we create specific documents. AH: I think the GEFEG model has more in it than we can capture in the spreadsheets. MB: Tony is proposing using XML for code lists and it makes little sense to propose something different for this. One approach would be a parallel one. The GEFEG tool is migrated along with the rules, the codelists are progressed by Tony's vision and we evaluate in the near term whether the method Tony has works. If you made it possible for submission to be in XML and you could process it via XSLT or GEFEG you would have a forward looking approach. GEFEG could give us an idea of what the data model looks like when they import it in to their too. Tony could build on that for the specific ideas that he has for code lists. JB: That assumes someone has done the work on the XML realization of the data model. MB: If that is something that could be provided in some format that Tony could look at that would be great. ACTION ITEM: Sylvia will investigate if this could be made available to Tony in some format. JB: Another big question is where does the resource come from to do the work regardless of the tool. IF we accept this proposal we will have the work that generates the schemas done for us by the tool. Is it understood that if we adopt this as tool the data model is still the product of the UBL TC. SW: That is correct. With respect to EF being used for 1.1 only, has any thought been given to what would be required to use it beyond 1.1? JB: The biggest impediment is that the internal data format is proprietary and opaque. IF that were exposed and open everyone would feel more comfortable. Assuming that the ebXML registry information model is perfectly enabled, we would have the standard XML representation that Marty was talking about, we would be more comfortable with EDIFIX. We would not be single sourced then on the supplier. SW: Issues for us would be resources and cost. JB: I am really not making any assumptions what lies beyond 1.1 in terms of this relationship. The critical issue is coming to a 1.1 issue of the code list spec, until that happens we can't begin to create final versions of the code list schemas. SW: We need to agree to what that spec is. The tool can populate the schema with a code list and sub code lists or portions of a code list. JB: The way those code lists are used is controlled by wired in rules. That part needs to be nailed down before any final schemas can be generated. We will have a 1.1 code list spec doc, and at that point, let's assume we have an EDIFIX guru to maintain the data model, that person won't be able to make the changes to realise the code list model. SW: We won't reduce the tech support to maintain the tool, it is just the data input resource that we are looking to reduce. JB: When the code list spec is final GEFEG will change the tool accordingly. SW: We will fully maintain, enhance and update the tool. TC: To what degree do we need to use GEFEG to do the code lists. JB: My impression is that we saved alot of work around that by using the fact that GEFEG has already built in the ordinary code lists. If we provide these separately, we incur the job of maintaining that representation. I think you are suggesting that we can provide codelists by a separate process. We could move the completion of 1.1 code list spec out of the critical path if we did late binding of the code list spec. The best strategy is to get early completion of a revised code list spec and use EDIFIX. As a fallback plan we can provide by alternative means these code lists schemas. If Tony and Marty look at this and conclude that there is a more congenial way for them to work, then I would not have a problem with that. SW: We would just like the final specs as quickly as possible. TC: In the long term I would like to see XML used. I don't have an issue with the EDIFIX approach in the short term. Agreed: Tony and Marty will continue to work on the code list spec. They will continue to work on the data model in XML format and will liaise with GEFEG on how this could be implemented. JB: Unless something comes up in the Pacific Call I am inclined to accept the proposal and I will probably put this to the TC in the coming days. For 1.1 we have had a very good relationship. GEFEG have been very accommodating and helpful, and we don't have many alternatives. AH: It would be good to have Tim talk to item 2 on the GEFEG proposal regarding the CCTS spreadsheets. Agreed to change CCTS data model to CCTS/UBL data model in item 2 of the GEFEG proposal. 3. STANDING ITEMS Event reports Reviewed, nothing new added. Liaison reports Done HISC report Deferred. Jon did add that this SC is looking for members to provide input. [SSC report: covered as part of EDIFIX discussion] Code List Team report TC: Input from SDML and MDDL has been received by Tony Coates. Tony is awaiting UBL input. Jon Bosak will check with Marty Burns if Tony takes team lead and Marty continuing to be editor. TBG17 Liaison Team report Done 4. OTHER ISSUES FOR DISCUSSION THIS MEETING UBL FAQ: Status report (Anne Hendry) It was agreed that this would be worked on by the SSC for now. UBL TC meeting in Santa Clara So far the following people have indicated they will be coming: Kim, Bill, Mavis, Anne, Jon, Eduardo, Sylvia, Peter Yim, Marion, Mike Grimley. Possible F2F agenda items: Reviewed. Addition of new items to the work list Alignment will be added. We will not have a call the week before we meet in Santa Clara i.e. 27 October
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]