Fwd: [codelist] codelist example

---------- Forwarded message ----------
From: G. Ken Holman <gkholman@cranesoftwrights.com>
Date: Apr 18, 2007 4:50 AM
Subject: Re: [codelist] codelist example
To: Ram Kumar <kumar.sydney@gmail.com>

Hi Ram,

At 2007-04-18 02:18 +1000, you wrote:
>We have some good debate going on in our TC regarding codelist specs.
>implementation in our V3.0. I have enclosed two schemas (for party
>names) that will give you an idea of how we are doing things.

I see that you are using XSD enumerations for 5 code lists (4 in
xNL-types.xsd and 1 in CommonTypes.xsd), and I see the four used in
one location each, and I see the one used in a number of locations.

I'm assuming those are your code lists ... they certainly look like code lists.

>Any suggestions
>on how this can be changed will be great.

Ram ... schemas cannot be "modified" to support the genericode code
list representation.

Genericode code list representation is *independent* of
validation.  It is just a list of codes.

A genericode file is not compatible with XSD ... there are no
validation technologies other than the one I created with UBL that
yet use genericode for validation.  However, if you wish, you can
translate a genericode file into an XSD file, or a RELAX-NG file, or
even a DTD fragment if you wished.

I can see three choices:

(1) - status quo: leave your code lists in native XSD form
     - ramification: one-pass validation
     - ramification: all document contexts use the same set of codes
     - ramification: user community cannot change the list of codes
       without changing the schema files

(2) - maintain two copies of the code lists: one in genericode and
       one in XSD where you generate the XSD form from the genericode
       form
     - ramification: one-pass validation, with preparatory step of
       creating the XSD fragment from the genericode file
     - ramification: all document contexts use the same set of codes
     - ramification: user community cannot change the list of codes
       without changing the published and standardized read-only schema
       files

(3) - maintain one copy of the code list and one in XSLT where you
       use
     - ramification: two-pass validation, with preparatory step of
       creating the XSLT fragment from the genericode file
     - ramification: different document contexts can use the same set
       of codes
     - ramification: user community can change the list of codes for
       any item in any document context without changing the
       published and standardized read-only schema files

You will have to assess which of the above you want to use.  If you
don't want two-pass validation, that rules out (3).  If you don't
need the features of a standalone representation of codes, that rules
out (2), and you are left with (1) which is the status quo.

Please let me know if anything above is unclear ... I really can't
advise you until you can decide which way you want to go.

Can you summarize how you thought genericode was going to be a
benefit for your committee?  Perhaps that will help me understand how
you anticipate using it.

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

p.s. if you read our summary you will see that genericode is not
*for* validation, but rather for any processing context (which
happens to include validation for those who want it for that):

  http://www.oasis-open.org/committees/codelist

Our charter mentions validation, documentation and management:

   http://www.oasis-open.org/committees/codelist/charter.php

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:   http://www.CraneSoftwrights.com/legal

ciq message