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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: SSC Report, 12 October 2004

SSC Report, 12 October 2004

The SSC discussed EDIFIX (EF) and the UBL development process this week.
Below is a discussion summary.  For complete details see the minutes 
posted at

Attached diagrams show a) the overall process envisioned in these 
and b) a detail of the 'Design and Modeling' phase showing areas in yellow
where EF would most be utilized.

Regarding EF proposal:

      It was agreed that Sylvia will prepare a user agreement which outlines
      specific features of EF along with how it would be used, how it would
      be provided, and details on training and suport.  In addition, the
      information below will either be covered in the proposal or 
provided separately.

      - Detail of what data is needed in a UBL submission for entry into EF.
      - Whether an .xsd or .csv output format could be implementable within
        the 1.1 timeframe.
      - A sample of the generic xml schema output format to be sent to 
      - A query posted to the ubl-dev list to ask what types of formats 
are in
        frequent use as intermediary interchange format.
      - A description of the origin of the content of the EF schemas:
        ss models, ndr rules, code lists, wizard parameters,
        other external standards, etc.
      - A review the CM Guidelines and statement as to whether EF supports
        them and how.
      - Description of which parts of the UBL ss model EF uses (or ignores).

How EDIFIX fits into overall process:

      - EF would mainly be used to create schemas.

      - EF may also be used to generate the CCTS data models.  GEFEG 
        that EF can be used for even more, but this needs further 

      - A prerequisite to using EF is the alignment of the current EF 
        output to the current spreadsheets.

EDIFIX input and output formats:

      - EF will take as input a spreadsheet in .xls format (generated
        either by Excel or OO), either the UBL format or the TBG17 format.
        so the following transformations will be supported:

        UBL ss -> UBL ss
        UBL ss -> tbg17 ss
        TBG17 ss -> UBL ss
        TBG17 ss -> TBG17 ss

Additional input/output formats:

      - UBL needs to decide on what transformation format is best for 
the TC.

      - GEFEG will assess the business cases for support of additional 

      - UBL is not currently requesting support for XMI format output 
for UBL,
        nor are we currently requesting native OO support.

      - UBL needs to know exactly what EF pulls from the spreadsheets 
and what
        parts are imported from elsewhere, as well as what parts are 
        hard-coded values in EF or generated by some other mechanism in EF.

      - UBL may need to make minor changes to the format of the spreadsheet
        models at times (eg adding columns).


      - There needs to be an exhaustive review of the compliance of the
        schema to the ndrs.  This should be done at the same time as the
        preliminary testing for consistency in output between the ss and EF
        is done (before we begin using EF).

      - EF would make it possible for those working on the NDRs to directly
        see the rsults of their rules on the schema, a great aid to rules

Code List support:

      - Tony is proposing xml as a source and transmission format for
        code lists.  EF already has functionality to allow one to specify
        which codes in the list you use but the methodology still needs
        to be specified.

      - Code lists have not been fleshed out yet.  This is a big concern
        for EF use.  We need agreement/decision on code list methodology.


      - UBL needs to maintain the existing ss format to a large degree for
        existing users and contributors such as the localization SCs.

      - It will be more difficult to change the tool to meet UBL practice
        (becuase EF is a product with many other user groups) so, 
        speaking we will have to modify some of our input practices to
        accomodate the tool.

Development environment:

      - EDIFIX is not a document management system, nor a source control 
        and not based on a client-server architecture.  Each instance of EF
        contains the entire model, on the local file system, so each person
        working on the model has their own version.

      - Merging changes will have to be done manually or through a proper
        source control system.  We can generate the required outputs from
        EF and then distribute them to UBL developers or users via other
        mechanisms: email, kavi, a server, etc.  We will continue to need
        a gatekeeper to manage changes with emphasis on an accurate change

      - The UBL change intake process should look at ways of versioning UBL
        that will not interfere with bringing in new changes to the model.

      - EF runs natively only on MS Windows.  This may limit who can do
        development.  It's possible it can be run on other OS's with an 


      - Training to be detailed further in the proposal.

      - Training will include some ubl-specific material and can be used
        to further explore some of the thoughts expressed above.

EF Reader:

      - The Reader provides several different views (eg. tree structure)
        of the standard in html, pdf, rtf, and for schemas, samples.
        The Reader is pre-bundled with a specific version of any standard.
        It is a valuable tool for business users to view progress/direction.
        Frequency of possible updates is yet to be determined,
        possibly monthly.


      - EF will not be used to produce the UML diagrams as released with 

Customization methodology support:

      - UBL 1.1 will require EF to support the CM guidelines/methodology.


      - Other UBL members (not GEFEG resources) will be using EF to do
        UBL development since GEFEG resources are already taxed providing
        tool development.

      - UBL is already resource-constrained and this process will take
        more resources.

      - GEFEG needs to know what the work requirements are going to be
        for EF (features) for 1.1 in order to allocate resources 

      - From a commercial perspective, GEFEG is committed to supporting UBL.

JPEG image

JPEG image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]