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: UBL data maintenance in EDIFIX


Dear UBL TC,

I would like to correct and clarify the original suggestions from Michael
Dill on how EDIFIX should be used for UBL data models and schema.  

In the work list dated 22.June.2004, on the schema generation tab, the
Status Column has the following statement " The suggestion has been made
that we make EDIFIX the master repository for all document models and
require all UBL maintainers and customizers to work with a free EDIFIX
license".  This is partially correct. We (GEFEG) did not mean that there
should only be one repository for all document models in EDIFIX that would
eliminate the spreadsheets. What Michael originally said in his 5.June email
was " The UBL name is not delivered because the schema generator generates
it from the parts of the Dictionary Entry Name. This is to avoid any data
redundancy and to make the model maintainable.  (But it could be used and
stored, if the UBL data would be stored originally in a modeling tool)." 

1) The storage of UBL data in EDIFIX data models does not mean that
spreadsheets would be eliminated.  
2) It does mean that the possibility exists to:
   a) Create a systematic approach to producing more accurate spreadsheets
and QA by providing a consistent mechanism for UBL TC members implementing
any changes to do so by using EDIFIX, 
   b) Having EDIFIX read spreadsheets and produce spreadsheets. 
   C) Having a QA team which could validate that both the spreadsheets read
and produced by EDIFIX are correct.
   D) Maintenance, extensions, and QA that is performed in a uniform,
accurate, and systematic way. 
   E) UBL TC members who want to derive schemas could do so as EDIFIX can
derive them from spreadsheets and data maintenance. If the results are
identical we can be sure that everything is correct. 
   FUQUA changes could be made in EDIFIX, and a comparison made to verify
that the input and output is the same. Another way to create spreadsheets
could be based on UBLish or something else.

Since we are not proposing that spreadsheets be eliminated, we believe the
request for a position paper to eliminate spreadsheets is not productive at
this time and would not solve our problems.  

What we are proposing is:
1) That the TC create a systematic, more accurate, and less labor intensive
approach to creating the UBL package and performing QA. 
2) That we agree on a process, procedures, and a team to perform QA. Such an
approach would also improve the quality of models, schemas and instances.  
3) That we have an approach that would allow us to verify that EDIFIX,
spreadsheets, and any other software tools produce the same results.
4) That we use UBL models to create both schemas and output spreadsheets,
thereby reducing the opportunities for errors from different sources. We
currently create models from one source, and schemas from documentation in a
change log. 

We all have many activities on our plates, and a UBL audience that is
expecting perfection even if we cannot deliver it. We need to find ways to
improve the quality of our work and shorten the time volunteers spend to do
it. We suggested a similar approach to the UN for the QA and maintenance of
EDIFACT and it has yielded successful results.    

Regards,
Sylvia




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