Re: [ubl] CodeList Conundra

[Tim McGrath <tmcgrath@portcomm.com.au>]

i can sympathize with your trying to track the source material and this situation
is one that all UBL should take responsibility for. the original problem
lies in the fact that the original CCT models and schemas were incorrect
and/or misunderstood. this led a chain of  confusion in both NDR and the
original code list mechanism, its inherent models, your paper and a lot of
subsequent debates.

the co-ordination meeting on wednesday  at 08:00 california time has an agenda
item to address one component of this - the module architecture. (related
to your questions 2 and 3)

also i can try and give my opinion on the questions you ask.

Burnsmarty@aol.com wrote:

All,

 

I am trying to help normalize the code list subcommittee draft to match the evolving schemas / models. Since I can assert that the contents of these (schemas models) relative to the code list paper were source material and no invention was intentionally done by the code list committee, differences have to do with my faulty tracking of the source material.

 

In addition, the code list representation in XMLSchema requires that for each code list there be defined a ComplexType, a SimpleType, and Attribute, a global abtract element, and a global element. I imagine that these components would be described in the abstract in one of the more abstract UBL modules and used in specific code lists.

 

Please provide me with guidance as to the following:

 

1) What is the normative data model for code lists desired by UBL is it the "model spreadsheet" or the models in the schema drafts?

we are gradually synchronizing the spreadsheet models and the schema drafts
- in the interim the source document has to be the spreadsheet models.  these
map the CCT structures into UBL models.  the schemas should be XML schema
expressions of these.

 

2) Where is the base class of a code list schema to appear --UBL-CoreComponentTypes-1.0-draft-7.1.xsd Code and CodeType? or in a new Code List Schema module, or, in UBL-CodeListUnspecializedDatatype-1.0-draft-7.1.xsd?

 

this is the item for discussion on the co-ordination all.  it appears that
your proposed architecture has been merged with the old code list mechanism
with the new and created some redundnacy which we need to resolve.  to put
this another way, becasue we did not follow CCT in the original schemas or
code list implementation we devised a work around module structure.  we don't
think we need this anymore . this should simplify the whole issue and answer
this question.

3) Where are instances of actual code lists to appear? Is this the subdirectory Stephen is aiming for?

 

again, stephen is suggesting two options.  have code content in the specialised
data type schema or have them in seperate schemas.  there are arguments for
both cases.  we need to decide on this today.

4) Why don't core component types that use code lists as an attribute use the code list schemas e.g. Amount.currencyID?

you almost answer your own question.  the Amount Currency. Identifier is
not a code, it is an identifier.  If it were a code it would be aclled Amount
Currency. Code.  UBL did not make these decisions it is given by the CCTS.

 

5) Why don't the core schemas that have standardized attributes use UBL-CoreComponentParameters-1.0-draft-7.1.xsd

two parts to this..

1. the current UBL-CoreComponentParameters-1.0-draft-7.1.xsd has many unnecessary
 (or at least confusing and unused definitions) and 
2. it is intended to define the metadata (not necessarily attributes, in
the XML sense) for BIEs.  most of these appear as documentation within an
annotation element.

 

6) Is it intended that all code lists have the same name within their namespace? It might be helpful to have a currencyCode named currencyCode where-ever it is used and not require its namespace to decode what its for (of course you need the namespace to uniquely qualify it).

surely this also brings into play versions of the same code list.  in fact,
i thought that was how we proposed to establish modnamver.  
i also thought the code list representation paper was advocating "physical"
code names (such as ISO4217Code.Type) as opposed to logical ones (such as
"CurrencyCode.Type").  I personally favour the latter but it is not the approach
shown in the examples.

 

I am ready to correct the code list document accordingly and provide examples of code list schema that meet the requirements of the code list committee model as soon as I can understand what to normalize against and which schemas to edit.

certainly, it does feel like we are not yet able to document the code list
representation.  i suspect this is because we haven't yet got a working implementation.
 in other words, we need to protoype this rather than design on paper.  What
Stephen has posted today is part of this protoyping.  Rather than try and
keep your document normalized it may be better use of our resources to work
together on constructing this protoype and then document what have built.

 

Thanks for helping a newbie,

Marty

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160