Re: [ubl-lcsc] [code:type-equivalence] Straw-man 2 Code list proposal - candidate final

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2003-09-11 02:33 +0800, Chin Chee-Kai wrote:
>Just some quick comments/suggestions before I disappear for the
>rest of the week.

Thanks for the feedback.

>1.  The reasoning for having a placebo that resolves ultimately
>into a xsd:token is to allow a generic validation so that local
>applications can check locally based on peer-to-peer agreed-upon
>code values.

Not quite, though the above is true.  In our code list teleconference we 
agreed that for many lists the "out-of-the-box" UBL would successfully pass 
all token values for code list members without any value checking.  It 
would be incumbent on the end user to choose to engage value checking.

>My suggestion is to try to do away with the current
>"placebo + MSDOS-Copy".

Two things that I've stated many times about this:

   (1) - MSDOS has *nothing* to do with it, I just happen to be using
         that for my development environment and the way I effect a
         file copy command happens to be with a "copy" utility; under
         GNU utilities I would use the "cp" utility.

   (2) - I have been *desperately* wanting to find an alternative
         technique and one *may* be available utilizing the XML Catalog
         facility, though I am unable to test this, so for version 1
         we are obliged (I think) to use the copy command.

It is unfortunate that you were not able to be present for the discussions 
the group has already had in this regard.

>Is it possible to look at using <xsd:choice>
>with one branch validating against, say, <cct:CodeType> (which
>ultimately resolves into a xsd:token), and a second branch validating
>against the local code list?

I believe this would provide no validation in any fashion because an 
invalid value entered by the end user would be acceptable by the xsd:token 
branch of the choice.

>Also, for proper validation for the locally coded lists (long
>list or short lists), we also need to consider publishing a
>formula for users to use in synthesizing a namespace that
>(1) users can associate with that list,
>(2) will be globally unique
>     (e.g.  my list of "apple orange peach" will have a namesapce
>     that is different from someone else's list of
>     "apple orange peach", because someone else could insert or
>     remove code values anytime while I might not want that to
>     happen at the same time)

 From our meeting yesterday my recollection is that your program will 
algorithmically synthesize the namespace for each code list from the 
Dictionary Name (perhaps from the Default UBL Name?) for the list ... 
whichever gives us a cross-UBL-unique contraction suitable for use within 
the namespace URI.

Each model schema will import those UBL code list definition fragments 
associated with the synthesized UBL namespace.  I believe there is no 
opportunity with which to substitute a user's namespace URI for the UBL URI 
without editing the model schemas.  It was thought that a copy command that 
replaces the code list definition wholus bolus is much safer than asking 
the user to edit URI namespaces in our files.  Also by providing a version 
of the definition file that is a copy of the delivered version, an end user 
can quickly restore the state of validation to the delivered state.

>(3) will be consistent with how code list namespaces are named
>     in UBL.

I'm not sure what you mean here ... if the only namespaces we allow are 
those synthesized by your reading of the spreadsheet, then they will be 
guaranteed to be consistent.

.................... Ken

--
Next public European delivery:  3-day XSLT/2-day XSL-FO 2003-09-22
Next public US delivery:        3-day XSLT/2-day XSL-FO 2003-10-13
Instructor-led on-site corporate, government & user group training
for XSLT and XSL-FO world-wide:  please contact us for the details

G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                       Definitive XSLT and XPath
ISBN 0-13-140374-5                               Definitive XSL-FO
ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:     http://XMLGuild.info
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc