Re: [ubl] CL schema and sdts [was Re: [ubl] Re: Outcomes of coordinationcall 10 March 2004]

[Anne Hendry <anne.hendry@sun.com>]

Hi,

I agree with and wanted to expand on a couple of Tim's points.  We just 
had a long discussion on this that spanned two subcommittee calls (Tim 
wasn't present), and the concensus there was also this:

- The only reason we have a cl udt file is because it was needed as a 
workaround to a problem that developed because of the way the original 
cct xsd from Gunther and Garret was constructed, and it was put there by 
Chee-Kai and Stephen to work around the problems caused by that original 
xsd file(s).   But the source of that problem has been fixed so the 
cludt  file is no longer needed.  In addition, the cludt holds only a 
single instance of a vanilla  code list datatype which is based on the 
cct code list datatype (basically a repeat in a different namespace). 
 In reality this code list udt is no different than any of the other 
unspecialized data types in the other udt, and separating it from the 
other udts may cause more confusion than clarity.  There may be one 
other reason it was considered to still be needed to be seprated from 
the other udt's - to resolve the possibility of a circular reference - 
but the only occasion this circular reference may be an issue, I've been 
told, is if someone was to want to use xsd validation on a code type 
that is contained within a supplementary component within one of the sdt 
or udt data type supp components.  Right now UBL doesn't do this nor 
need to do this.  It would be straight forward for the CLSM to be based 
on the CCT xsd directly, even, and Stephen has tested out the 
feasibility of doing this and, as Tim mentioned, found it to work - the 
instance validated.  (Even that physical dependency on cct may not need 
to be manifest over time since cct is a conceptual model -  we already 
leave out the more basic origins of the CCT intradependencies, so it's 
just a matter of where you want to draw the line betwen conceptual and 
physical).

- In terms of ccts conformance, I also don't see where ccts says 
anything about what we're discussing.  Mark, can you be more explicit?   
Obviously the claim that this is unimplementable has been proven wrong 
by Stephen's excercise, though.

- In terms of the clsm, the only reason I have garnered for even having 
the clsm is to allow for the creation of an xsd file for each code list, 
and to allow others to plug and play these lists.  However, part of the 
discussion recently determined that we don't want pluggability for 
things we deem to be set in concrete for UBL, which has raised the 
question of whether we should move the truly standard (internal standard 
- created/owned by UBL) codes into the sdt and only leave the ones that 
are 'external' standard (provided by UBL but owned in the end by others 
and replacable) as clsms.  Because, if there are some codes we want to 
be truly UBL standard, we really *don't* want that pluggability, even at 
the schema level, we are not achieving that by having them as clsms. 
 There are only possibly 4 codes we are currently specifying that would 
want this pluggability (substituting other schemas for the ones we have 
as clsms).  They are country, currency, channelcode and 
paymentmeanstypecode.  All the others are very UBL specific and we 
wouldn't ever want anyone to change them anyway without using a UBL 
release that specifically updated them as we have defined total 
ownership of them.  This is another question that probably can wait for 
discussion for the next release, but it is something we should clarify 
sooner than later.

For this release we just need to be careful that we are not specifying 
as 'standard' (required) something that we really don't need to have 
required, and are not leaving the door open to pluggabilty for something 
we don't want to be pluggable.  Not all codes are created equal.  As Tim 
noted, some of these codes are not really codes - they are 
enumerations.   Has anyone reviewed the 13 listed codes to make sure we 
still all agree these are absolutely necessary to be specified by UBL 
(as opposed to allowing them to be placebo and be detemined by partners 
outside our purview) or as opposed to having them in the sdt and 
therefore circumventing any pluggability?  They are (# of elements in 
parens):

chipcode (2), substitutionstatuscode (2), channelcode (40), 
linestatuscode (5),
longitudedirectioncode (2), latitudedirectioncode (2), paymentmeanscode 
(50),
documentstatuscode (4), operatorcode (2), aknowledgementresponsecode (2),
allowancechargecode (50), countryidentificationcode (300+), currencycode 
(200+).

All other codes used in UBL are totally open for substitution (w/o 
validation).

-Anne

Tim McGrath wrote:

> this decision was made on the basis that we have implemented this and 
> found it to work.  what michael and gunther may not be aware of it 
> that the new CCT.xsd has all the components that the now defunct 
> CDULT.xsd has. 
> also i cannot see how this has anything to do with CCTS conformance - 
> this is a schema modularity issue - when did CCTS start designing 
> schemas?  what CCTS defines is a logical solution - not a physical 
> implementation.  provided we support the features of CCTS, how we do 
> this in XSD is up to UBL.
>
>
> CRAWFORD, Mark wrote

> 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
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. 
>>
>>
>>  
>>
>