[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SSC Minutes, 7 Oct 2004
The UBL Software Subcommittee met on 7 October 2004
at 16H00 - 17H00 UTC and at 00h00 - 1h00 UTC.
Present: Tony Coates, Stephen Green, Anne Hendry, Sylvia Webb.
Agenda:
1. EDIFIX (EF) and the UBL development process
Pre-reading
-----------
http://lists.oasis-open.org/archives/ubl/200410/msg00003.html
http://lists.oasis-open.org/archives/ubl/200410/msg00013.html
Summary
-------
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.
(S1) Detail of what data is needed in a UBL submission for entry into EF.
(S2) Whether an .xsd or .csv output format could be implementable within
the 1.1 timeframe.
(S3) A sample of the generic xml schema output format to be sent to Stephen.
(S4) A query posted to the ubl-dev list to ask what types of formats are in
frequent use as intermediary interchange format.
(S5) A description of the origin of the content of the EF schemas:
ss models, ndr rules, code lists, wizard parameters,
other external standards, etc.
(S6) A review the CM Guidelines and statement as to whether EF supports
them and how.
(S7) Description of which parts of the UBL ss model EF uses (or ignores).
Discussion Details
------------------
How EDIFIX fits into overall process:
EF would mainly be used to create schemas. The use of EF will occur
after the business modeling and assessment (traditionally done by
the LCSC and shown in the overall UBL development description as
the 'Design and Modeling' phase) has been completed, and after the
necessary bies, codes, messsages, and other changes have been
approved by the TC.
GEFEG also proposes that UBL uses EF to generate the CCTS data models,
including maintaining them and generating both schemas and spreadsheets
from them. We are doing this today.
We need to know what information EF needs for the entry of a new
UBL object or update to UBL into EF. Sylvia will detail this in
her proposal (S1).
EDIFIX input and output formats:
EF will take as input a spreadsheet in .xls format (generated
either by Excel or OO). It would be easier for GEFEG if multiple
small changes were bundled into one ss.
EF will accept spreadsheet input in either the UBL format or the
TBG17 format and will produce both UBL and TBG17 compliant output.
So the following transformations will be supported:
UBL ss -> UBL ss
UBL ss -> tbg17 ss
TBG17 ss -> UBL ss
TBG17 ss -> TBG17 ss
This will be beneficial in terms of helping users move over time
to the tbg17 spreadsheet format if UBL decides it wants to adopt
this format. It would be helpful to UBL to understand what parts
of the UBL input ss EF relies upon so we can change the ss if
needed and not impact EF negatively. (S7)
There have been requests for serveral other input formats to be
accomodated. It was agreed that for 1.1 development and 1.0
maintenance within the 1.1 timeframe, the spreadsheet format will
be sufficent.
One prerequisite to this, though, is the alignment of the current
EDIFIX output to the current spreadsheets. This was detailed in
last week's meeting minutes.
Additional input/output formats:
UBL itself is trying to identify a uniform transformation format
for the model and needs to decide more formally on whether .xsd
or .csv or another format is best for the TC. This applies to
output format as well.
As discussed in the code list methodology paper submitted by Tony
Coates (see 'Code List support' below), xml can be a good source
and transmission format for code lists and it can be transformed
relatively easily into other formats using stylesheets. This may
be more manageable than csv, so this should also be taken as a
consideration. An additional advantage of any text-based format
(.xsd, .csv, .xml, etc) is that it could easily be stored in a
repository with version control. GEFEG will begin investigating
the possiblility of handling input in .xsd and/or .csv format for
future work, but needs agreement from the TC before proceeding
very far on this (S2).
EF currently supports output to an auto-industry-specific xmi format.
Any new xmi output format support by EF would have to be specifically
requested. We are not currently requesting support for XMI output for UBL.
EF also has a generic xml schema output format that is designed to
suit how EF holds a model internally. Sylvia will send Stephen a
sample of this (S3) to investigate as a possible intermediary/hub
point that could be used to transfer updates in and out of EDFIFIX,
removing the hard dependency on the spreadsheet, at least for 1.1,
while other options are investigted. It would also be helpful to
query the ubl-dev community to find out what formats are in most use.
Sylvia will post a query to the list (S4).
Open Office output is not consistent in how it outputs columns and
rows, otherwise it might have proved suitable as a interchange format.
OO also doesn't seem to completely implement the OASIS OO file format
yet but this is likely to be implemented later, perhaps making it more
suitable then.
Different parts of the schema are produced from different inputs:
the UBL model ss, the NDRs, external information such as code lists,
other standards such as ccts and iso 11179, rfc 2131, etc play a
role as well. Then some parts of the input come from hard-coded
values in EF. UBL needs to know exactly what EF pulls from the
spreadsheets and what parts are imported from elsewhere, as well
as what parts are EF hard-coded values. There are several reasons
for this. One is that UBL wants the freedom to change parts of
the spreadsheet if necessary, but want to make sure changes are
only done that don't negatively impact EF processing. Another
reason is that UBL needs to know where the components of the UBL
normative deliverables are coming from - from the model spreadsheets
or other inputs. A third reason is that parts that are hard-coded
(programmed directly) into EF can result in mismatches between ss
and schemas when the ss are changed. In order to address this reason,
as much model data as possible needs to be available in the speadsheets
so the amount of hard-coding in EF can be minimized.
In the end, though, everything can't be represented in the spreadsheets,
so there will be some amount of infomation EF has to generate itself.
Sylvia will talk to the engineers and provide documentation on this (S5).
NDRs:
There has not been 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 schame, which would probably
be a big help in rules development.
Some of the schema content that may never be in the spreadsheets
is output required by the NDRs. Some of this is minor (punctuation,
etc) but some is significant. For instance, the naming rules for
UBL names seems to be hard-coded into EF. Changes in these types
of data could be handled by an 'options' file, mentioned below.
Code List support:
Tony will be proposing xml as a source and transmission format for
code lists. so part of this is how much people envision using EF
to maintina 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. This will very possibly require
changes to the cct and datatypes schema. Code lists have not
been fleshed out yet. This is a big concern for EF use.
ISSUE: 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.
We reiterate here the need to know how the data in the schemas is
gnerated - either wizard params, hand coding, ss import, or
otherwise. It may take some time to document this, so Syliva will
add this to the EDIFIX list of deliverables for 1.1 development but
it is not a prerequisite to making a decision on EDIFIX use (S5).
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 client-server architecture. Each instance of EF
contains the entire model, on the local file system, as it is being
developed. This means that each person working on the model has
their own version. EDIFIX is not a document management system,
nor a source control system. There are methods available within
EF to manually assign version and variant identifiers to specific
files, but this is completely under the control of the user.
There is no merging capability when a new version of a file is
entered into EF. The user must manually assign a new version to
the information being entered in order for it not to overwrite
the existing information. You can enter changes to the Order
document independently of changes to the Invoice document and they
are both accepted if they do not cause conflicts with other parts
of the existing model. Consistency checking is done on input.
If there are inconsistencies detected on input, if they are
fatal errors, EF will block input, but on other inconsistencies
the user can manually override.
Multiple people cannot be working on the same part of the model
(ie. document) at the same time without creating merge problems.
Any merging will have to be done manually or through a proper
source control system. Because of this it was agreed that only
one person would work on the model at one time. Changes will
be serialized much like they are now, although we will have
a central repository (EF) for the results. This means that in
order for those working on UBL to receive changes from others
working on UBL we will have to post chagnes regularly as zip
files, either on PY's server or Kavi. We can generate the
required outputs from EF and then distribute them to UBL members
via other mechanisms for further development or viewing.
With this system we will still need a gatekeeper to manage changes,
as we have had in the past. It would be helpful to have a location
such as Peter Yim's server where anyone working on ubl could gain
access to the latest set of files. Another option woudl be to
have the files posted on Kavi or straight to the mail list,
as has been done in the past. This will require the same
'change logging' process we've had in the past. We can enhance
this somewhat with a source control system such as SCCS or even
Ant, if we have use of a server. Will OASIS provide such a service?
This was discussed in earlier meetings regarding Kavi shortcomings.
Anne will investigate this further.
The scenarios and capabilties outlined abvoe make it even more
necessary to do consistency/alignment checking during the modeling phase.
We should attempt to bring as many changes in at the same time to
reduce the problem that might otherwise occur where one submission
chnages or negates or somehow causes conflict with an earlier one.
Syliva mentioned that EF has a capability of entering notes at points
where submissions may come into the model. It is part of the TBG17
Reader which can be downloaded from the GEFEG site. This is not
something we need now, but can investigate in the future. Basically
the process of taking in requests for UBL will require a mini-
harmonization effort and we should look at ways of versioning UBL
that will not interfere with this - should be able to update parts
at a time and not need to recreate waht is not impacted by the change.
EF only runs on MS Windows. This may limit who can do development.
It's possible it can be run on other OS's with an emulator (vmware?).
Sylvia knows of one user who is running it this way on a Mac.
Training:
Training will include some ubl-specific material and can be used to
further explore some of the thoughts expressed above.
EF Reader:
There was some discussion in the TC meeting Wednesday whether the
Reader could be used to view the ongoing development. The Reader
provides several differnet views of the sntadard, such as html
pdf view of the tree structure. The Reader is pre-bundled with
a specific version of any standard. So when someone downloads
a Reader version, along with it comes the version of the standard
that was last packaged with the Reader by GEFEG. It would be possible
to have GEFEG bundle a new verison of the UBL standard with the
Reader approximately once a month during the development phase.
This would be valuable for business users to view progress/direction.
However, a big asset gained by using the Reader would be if it
could highlight, in the html or pdf version, the diffs from the
previous version. The Reader can currently export xsd, pdf, html,
rtf, and for schemas, samples.
UBL will use other methods of distributing the outputs during
development, as mentioned above, to those doing development, or
those who need more frequent updates than the Reader can provide.
UML:
EF will not be used to produce the UML diagrams as released with 1.0.
Customization methodology support:
Need CM support for 1.1 as all 1.1 changes must follow CM guidelines
in order to be considered a minor relase.
Sylvia believes cusomization is supported, but will review UBL
Customization Guidelines document and let us know if this is
supported (S6). Anne will add 'derivation methodlogy considerations'
to the modeling phase of the UBL process.
Resources:
Sylvia voiced a concern about having enough UBL resources to impelment
any of these ideas. EF cannot provide the resoources to manaage the
tool and do the UBL development. Other UBL members (not GEFEG
resources) will need to be the ones using EF to do the UBL development.
It will help if we get started early resolving issues that will
otherwise come up later, such as derivation/customization implementation.
Things become simpler once there is agreemnt on how to do them.
This process will allow the technical poeple to get involved much earlier.
AI for Anne:
Investigate whether OASIS now has the ability to provide a server
that can be used as a source repository (not Kavi).
2. Other business
Syliva asked how the business model came to be and where woudl one
go to find info that supports the business model? None of this
appears to be captured in an identifiable location.
The answer to this is that it is in multiple meeting minutes and
in the minds of those UBL members that worked to create it, including
those such as Mike Adcock who are no longer with us. The buiness model
development process cast a very broad net and was only accomplished
because of the many internationally recognized organizations that
provided their knowledge of world-wide buisness practices. Subsequent
reviews have upheld the belief that UBL captures the requirements of
most of the business entities around the world. See papers from IDA
(http://lists.oasis-open.org/archives/ubl/200408/msg00026.html) for
a recent gap analyis done with UBL.
The problem of a lack of documentation is acknowledged,
and if we could docuemnt this in EF in extended docs tht would be great.
This would further an work item that has been floating around for some
time to improve the docuemtnation beyond the definitoins we have now,
including some clarificatin of terminiloogy that would help the
localization efforts.
3. Requested additions to the November F2F meeting:
- convergence in ss output format with tbg17 (Y/N? Issues resolution.)
- review of ubl / NDR alignment
- commitment to 1.1 feartures that will allow GEFEG to allocate resources
SSC Pacific call:
Present: Sylvia, Anne
GEFEG needs to know what the work requirements are going to be for EF
(features) so Sylvia can get some type of idea of resources and budget impact:
how many users, training, where located, support requirements, etc.
Sylvia will add some info on GEFEG target markets and why GEFEG is
willing to do this work (ROI) so UBL has some idea of GEFEG priorities.
GEFEG has a editor-only low end product which is configured for a
specific standard, like the Reader. It competes with XML Spy.
More info on this is available on the GEFEG web site.
We need to come away from the San Francisco F2F with a good understanding
of what is req'd for resource commitements. From a commercial perspective
GEFEG is committed to supporting UBL.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]