OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ssc message

[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]