Resend: Code list document structure discussion (2005.04.25)

[jon.bosak@sun.com]

Kavi appears to have suffered some indigestion trying to process
the code list draft posted by Marty Burns 25 April:

   http://lists.oasis-open.org/archives/ubl/200504/msg00109.html

I think we all got the mail that Marty sent, but in an attempt to
store this in the mail archive, I'm putting the package back
together with some reworked MIME headers and attaching it below.
Note that the file with the .zzz suffix has to be renamed .zip in
order to unpack it.

Jon

==================================================================

date: Mon, 25 Apr 2005 11:40:30 EDT
from: Burnsmarty@aol.com
subject: [ubl] Code list document structure discussion
to: ubl@lists.oasis-open.org

All,

Below, please find a sequence of email fragments from Tony and I
discussing the integration of Tony's code list data model with the
ubl code list draft document. Attached are two versions -- one
proposed by Tony, and, one edited by me to show each approach. The
committee can use this email and attachments as the basis of the
discussion on guiding the code list subcommittee on how best to
proceed.

Under separate cover, I am readying a document presenting the
alternatives to code list schema representation.

Cheers,
Marty  Burns
President
Hypertek, Inc.
14624 Country Creek Lane
North  Potomac, MD 20878
P +1(301)315-9101
F +1(301)217-9503
C  +1(301)257-9101
E _burnsmarty@aol.com_ (mailto:burnsmarty@aol.com) 

____________________________________

>From ABCoates:

Attached is an updated version of the code list document (in a variety  of  
formats).  What I have tried to do here is two  things:

(i) reorganise it into two sections - first the generic section,
then the UBL-specific section;

(ii) add  the details of the  generic code list format (aka 'genericode').

As part of this, I have attempted to separate the requirements
into two sets - first the generic requirements, then the
UBL-specific requirements.  My thought is that any mention of
ABIEs, BBIEs, and NDRs should only occur in the UBL-specific
section.  I also think that discussion of the particular W3C XML
Schema structure used by UBL should also be in the second section.

The new first (generic) section is mostly an import of my XML 2004
talk, with some small changes to make it more suitable for the
document.  However, what I have done is very rough, and still
needs a lot of editing.  However, having the document in this
format will make it a *lot* easier for me to continue the
development of the generic side (working with FpML & MDDL),
without forcibly impacting the UBL side of the document.  I do
have some things to add still, based on the feedback I have
received so far.

____________________________________
 
>From MJBurns:

Tony, I think that your excellent contributions should fit into
the structure of the document we had. There is no need for a
ubl-specific part and a non-ubl-specific. Just a data model and an
XML Schema mapping. The concept is to converge efforts toward a
solution set -- not parallel solutions.

To that end, I have tried to remove the UBL specific references
from the requirements and have adopted your rewording. Then, I put
your theory of code list modeling into the introductory portion of
the document. I needed to merge your copy by hand because you
worked from an older version than the current.  There were a
couple of your new requirements that I thought were part of
existing requirements and so I either discarded them or added them
to the existing descriptions. I also preserved the original
numbering since no one will be able to compare requirements with
the renumbering in your draft. You need to check if I captured all
requirements and comments correctly.

We need to gain some agreement on the actual data model and how
its presented in section 4 followed by the schema representation
in section 5.

How do you feel about my edits to your proposed edits? Can we work
on this document from this point to do the edits you suggested
would be necessary next?

____________________________________

>From ABCoates:

I guess the biggest thing is the inclusion  of the code list data model  
sections into the introductory  chapter.  At the start of 1.5 you have  
written:

"I am not  sure that we can fold this entire section in as is. Not sure  
what to  do with the WXS model stuff."

I completely agree with you here.  We can't fold this stuff into
the introduction, before reaching any of the requirements.  This
is why I thought we needed two documents in the first place.  One
with the original structure of the code list document, the
structure you are trying to preserve, and one that is a generic
description of the code list model.

____________________________________

>From MJBurns:

I will mention that I wasn't suggesting that your "columns" design
only appears in the introduction. I think that your theory and
analysis makes sense there. However, we would need to extend the
data model section, 4, to explicitly embody the column concept. It
should also collapse to a one dimensional result, I think, until
new columns are defined. What do you think?

____________________________________

>From ABCoates:
 
My intention was to describe a comprehensive "generic" code list
model, one that didn't buy into any groups specific requirements
for particular columns, keys, or metadata.  So yes, I do consider
the specification of which metadata items should be in a UBL code
list to be, more or less, UBL-specific.  You could argue about
whether it is UBL-specific, CCTS-specific, UN/CEFACT-specific or
what, but what we do know is that those are not prescribed
metadata items for FpML or MDDL, among others.  That is what makes
those "specific" requirements.  I don't have a problem with UBL
having such specific requirements, I can't see how UBL could work
if it didn't have such specific requirements.  However, I can't
sell a code list solution to other groups if it mandates such
specific requirements.  This is why the model I presented was
designed to provide the necessary framework, while being agnostic
to the specific items that particular groups will require in their
code lists.

____________________________________
 
>From MJBurns:

My desire is that the code lists that are created are mainly by
third parties -- not UBL, FpML or MDDL. Yet, they can be used by
these groups. The ubl metadata is a good set of metadata. Only
several of the pieces would be required to satisfy requirements of
a good code list model -- version and source info for example.

That being said, at worst case I can imagine having a separate UBL
metadata section although I would prefer to represent it as
suggested metadata and have a universal solution. If non-critical
fields are optional than could this work for you? Are there
required metadata for versioning and such in the FpML and MDDL
work? Also, is it the metadata items that are different or what
they are called?

Finally, the data model has two parts -- the metadata for the code
list, and, the codes themselves. I think the latter very much in
non-ubl specific and wants to capture your flexible model as its
basis.

CodeListDiscussions20050425.zzz