[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SSC minutes, 30 Sep 2004
The UBL Software Subcommittee met on 30 September 2004 Agenda: 1. 1.0 comments/issues update Recent questions from ubl-dev which should be added to the FAQ: - Why there are no cc's evident in UBL deliveries AI: Anne will consolidate answers to recent questions 2. Additions to 1.1 requests (for current list see Jon's posting) Discussing in taxml: - certificate of residence (COR) - indirect taxation (IT) It would be helpful for UBL to clearly define its scope and roadmap so other organizations can know if their work might fit within the scope of UBL. Other organizations can create ubl compatible schemas without being part of the UBL library but some don't want to do the schema work. Otherwise what's the benefit vs. developing their own? Need guidelines for prospective developers. 3. 1.1 process One issue has been about the proprietary nature of tool(s). With edifix models can be written to ss. Currently can also write one xml format (odet/automotive) but not other xml formats. But can write the model to schemas. If we take gefeg files and open with zip, some files are xml, but not all. Sylvia will investigate this file format more and see if it's something that would be useful to us in the development process. UBL Development Processes (first draft from Copenhagen) See attachment 'ubl_dev_process.txt' and accompanying diagramatic version. 1. Requirements Gathering UBL will accept submissions for new documents but generally won't otherwise add to the library as resources are already very constrained. 2. Design/Modeling Phase A critical prerequisite to beginning work with EDIFIX is to complete the tool so it can receive a spreadsheet and produce schemas that exactly represent the spreadsheet. This would put us at a good starting point. Steps: a. take in ss in existing 1.0 ss b. generate a new set of schemas c. diff the schemas with 1.0 schemas d. then generate ss and do diff with 1.0 ss Issue: We should align the ss format with tbg17 as we move forward; however this presents problems for original and current users unless we preserve backward compatibility. If we do introduce the tbg17 format EDIFIX could take in the old format and produce the new format. This would help people move to the new format. It was agreed we would pursue this solution. Tools availability, Training, and Support A limited license to EDIFIX would be made available for ubl workers. Training could happen in US or at UBL meeting. There is internet training software. Support would be through Sylvia in the US, and in Berlin. Will get same support as paying customers. Concern about not having access to all the information used to create the UBL release can be allayed by storing the results of each production cycle. We do still need to identify a physical location for the cannonical artifacts we want to preserve. Others may not need to use edifix. Rules can now be taken from ndr. However the purchase provides maintenance and updates at no cost. GEFEG may come out with a ubl editor with ubl schema. AI: Need to find out what NDRs are actually implemented in 1.0 release. Part of QA, but EDIFIX can help since David has this info as well. The rest of the process wasn't discussed since we ran overtime. Issues: 1. Can David be available for meetings or for ubl-dev to share info. People want/need the tool (any tool) to be more transparent. That can't happen if the people who know its internals are not available. Currently others (eg. Chee-Kai) are answering questions. But we need someone comparable with EDIFIX knowledge to answer if we use EDIFIX. AI: Sylvia will ask if David can join ubl-dev, but she will monitor and point out which messages he may want to respond to. 2. We don't have open source and therefore don't have free tools. However, nothing is produced by EDIFIX that can't be used with open source ides. Basic dev activities can be done with any other ide to extend schema. Tools group can find and encourage open source solutions. For producing the UBL packages, though, edifix provides some superior features. We won't have the advantage of leading by example in this area, but we can make up for that in other ways. We'll need to do this because local egov won't be able to afford edifix – they are barely able to afford xmlspy. There is a version of edifix that competes with xml spy. There are no tools other than edifix that handle both mnodels and schemas. 3. Support of open standards – oo and xslt. Whenever we produce something we produce it in other open formats as well. There is some possibility of producing xml output. edifix is looking at output in java and xslt, but no date for availability. edifix models are umm – maybe providing xmi, but can also produce schema. All these things egovs will look at. Must be able to take in oo generated excel ss (or an oo ss). AI: Anne send oo transformed xls to sylvia. 4. Need source in tool AI: Anne send Sylvia original tools requirements list from London. edifix output is stored in binary, so limits what can be done with source control. RFEs for EDIFIX: automated change logging and source versioning. Need something which allows us to check changes to ss via a diff-able file format (eg. xml). AI: Anne look into setting up source control tree on Peter Yim's server. 4. Reports/updates from SCs / work teams / implementors No other reports today. 5. Other business - web page review Original tools requirements from May 2003: a) non-proprietary storage format b) availability on multiple platforms d) configurable to syntax rules e) configurable to customization rules f) provides version control g) requires no manual editing h) supports XMI change format i) is an integrated tool set j) provides collabortive central source repository k) enforces a controlled vocabulary l) provides a single data/source repository m) low (no) cost
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]