Re: [ubl] Re: Outcomes of coordination call 10 March 2004

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

marty's proposal is similar to what we did for 1.0-Beta, provided empty code
sets which validated everything.

I am not sure we gain much from having null code lists.  i prefer the idea
that BBIEs which have codes for which the codelist is not defined by UBL
are 'unqualified' data types (in CCTS jargon) and therefore defined in the
'unspecialised' data types schema (in UBL jargon).  that is, they are just
CodeType.

Is it possible that anyone wishing to implement their won codes could create
one from a template and update their own models/schemas accordingly?


Burnsmarty@aol.com wrote:

In a message dated 3/11/2004 11:46:58 AM Eastern Standard Time, MCRAWFORD@lmi.org writes:

Jon wrote:

     Remove CLUDT, and where references were made in the document
      schema modules and aggregate schema module to CLUDT, now
      refer to UDT, and where references were made in the code
      list schema module to CLUDT, they are now made to CCT.
      Namespaces are revised accordingly.

According to Michael and Gunther your solution creates recursion problems with the datatypes schema module and breaks conformance with CCTS.  Michael and Gunther have expressed serious concerns to me today that this decision is unimplementable.

Mark

Mark,

 

I was trying to understand the application of the CLUDT in the schemas. Looking at the usage in the aggregate schema module and in the Invoice module, the CLUDT is used when a code list with no codelist definition schema is used. This in essence is the "null" or "any" code list. Could this make the CLUDT just a peer to other defined code lists instead of as a parent? What is the nature of this unspecified code list? What values does one expect to put in the supplementary components if they are present?

 

Would it be worthwhile for UBL to define a codelist schema for each and every unique codelist used by the library so that there is a "nucleation site" for standardized values to grow and versioning, etc... even if no standardized values are known now?

 

 

Thanks,

Marty

 

Marty

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