Software SC Report, 6 October 2004

[Anne Hendry <anne.hendry@sun.com>]

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