[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
http://lists.oasis-open.org/archives/ubl-ssc/200410/msg00003.html.
Attached diagrams show a) the overall process envisioned in these
discussions,
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
Stephen.
- 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
proposes
that EF can be used for even more, but this needs further
discussion.
- A prerequisite to using EF is the alignment of the current EF
ss/schema
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
formats.
- 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
currently
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).
NDRs:
- 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
development.
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.
Maintenance:
- 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,
practically
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
system
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
log.
- 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
emulator.
Training:
- 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.
UML:
- EF will not be used to produce the UML diagrams as released with
1.0.
Customization methodology support:
- UBL 1.1 will require EF to support the CM guidelines/methodology.
Resources:
- 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
appropriately.
- From a commercial perspective, GEFEG is committed to supporting UBL.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]