[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Software SC Report, 6 October 2004
Software SC Report, 5 October 2004 For details of last meeting see http://lists.oasis-open.org/archives/ubl-ssc/200410/msg00001.html. We spent a good deal of the meeting discussing incorporation of EDIFIX into the UBL development process which is outlined in the attached ubl_dev_process.txt and the accompanying jpeg diagrams. These should provide some context for review of Sylvia's EDIFIX process diagram. EDIFIX use mainly comes into the Design/Modeling and Technical Production phases. The following decisions were made: Design/Modeling Phase a. EDIFIX agrees to allow input via spreadsheets for both internal and external developers. This leaves the question of what format the spreadsheets should be. EDIFIX would like to see tbg 17 format. UBL needs to suupport prior and current users. We agree to migrate gradually maintaining backward support for as long as needed, but with the goal of eventually aligning with tbg17 format. To encourage this, GEFEG will take in the old format and give back the new format to make it easier for people to move to the new format when they're ready. b. A precursor to final agreement to the use of EDIFIX is that there must be an 'initialization' excercise in which we take the current 1.0 ss into edifix and produce new set of schemas that we diff with the 1.0 schemas. After resolving any discrepancies there we then generate ss from them and do a diff with 1.0 ss, resolving those discrepancies. This will set us on known, consistent, and aligned footing for going forward. c. We cannot require our users to use Excel. We have tested EDIFIX to make sure it can read the spreadsheets that were released with 1.0 after those ss had been opened in OO and saved in Excel. It worked fine. EDIFIX cannot read straight OO files but we have raised this as a possible RFE as the need will very likely become more prevalent as more govs and oasis folks use OO. In the meantime, though, this is a great start. Looking forward, a common output format would be wonderful as well. We discussed the fact that EDIFIX exports to xml, but it's not sufficient for a complete capture of internal information. There has been some discussion of having EDIFIX use schema for a cannonical representation. Many people feel xml is enough. This is something that will continue to be debated. d. Training/Support/Documentation There will be a limited license made available for a subset of UBL members who are doing development. We discussed a 'gatekeeper' who would be one of the folks using the tool and making sure we maintained back versions of everything. Training would be done in the us/west coast (by Sylvia). Probably couldn't go to Asia to do this, though might be able to do it at UBL meetings, and internet training available. Is this workable? Support would be Sylvia front line and Germany (David?) back line. We still need to work out timeframe commitments (available hours, how much time is reasonable to expect, etc). At one end of each change cycle we'd archive all the outputs of the tool in case we lost the license. Any open source ides can be used to work with the artifacts if users so wish. Ongoing Maintenance Phase NDR rules compliance of current schemas needs to be specified. GEFEG can help with this. Issues: 1. David not on ubl-dev. Sylvia will talk to them about getting him on. 2. We don't have open source but need an alternative. Many organizations will not want to pay for EDIFIX. EDIFIX has a low-cost version which competes with xmlspy. We should get more information about this. 3. We are still grappling with what format to use as a cannonical format. It's impossible to store the ss in a source control system so it would be great to find a format that is both easy to develop in and easy to store, or an interchange format that could capture all the information we need about the models and still be in some type of ascii. Schema itself has been suggested, but also xml. It's still up for discussion. 4. EDIFIX doesn't provide versioning or source control. We nned to keep back versions of our artifacts to compare against and in the event we lose something. We discussed using Peter Yim's server for this. There is an RFE for EDIFIX to add automated change logging and source versioning. We will need to continue to keep a manual log of all changes to the ss models and schemas. 5. We discussed the original tools requirements list, most of which is still relevant. Sylvia looked at this and will discuss with EDIFIX. Perhaps we could take the output of this excercise and incorporate it into a GEFEG proposal document with questions answered. This will give us a better understanding of the features and boundaries of the project.
1. Requirements Gathering a. Requests for features b. New business cases c. Interoperability reviews d. General reviews 2. Design/Modeling Phase a. Submission Acceptance [new, update, fix, ..., or internal update] b. Submission Review/Assessment [Busines, Technical, Logical, ...] Check submission against existing BIEs and CCs Review business applicability/alignment c. Submission Modeling Model BIEs (SS?) Enter model into EDIFIX d. Submission Harmonization Align with existing CCs - create/define new CCs as needed. e. Submission Integration f. QA 3. Technical Production Phase a. Schema generation b. HISC work c. ASN.1 d. Localization e. Other deliverables (UML, Examples, etc) f. Documentation g. Review/QA 4. Release Phase a. Packaging b. Publication to vote c. Comment review/incorporation 5. Post-Release Phase a. Marketing and Liaison activities b. Maintenance 6. Ongoing a. NDR development/alignment Rules review Rules application (applicability) b. Alignment with CCTS c. TBG17 submissions/alignment