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

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: Tim McGrath <>
To: 
Date: Fri, 12 Mar 2004 14:41:14 +0800










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?



 wrote:

 
  
 
  
 
   
  In a message dated 3/11/2004 11:46:58 AM Eastern Standard Time, 
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