Re: [xml-dev] RE: 4 approaches to structure lists, plus an analysis of e

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

At 2009-02-19 10:12 -0500, Costello, Roger L. wrote:
>I started learning the approach to creating lists that Ken 
>described, called genericode. I will call that Approach #4. Below I 
>review the first three approaches, then describe Approach #4.
>
>Approach #1 - Express the list using the XML Schema vocabulary, e.g.,
>
>     <xs:simpleType name="countriesType">
>         <xs:restriction base="xs:string">
>             <xs:enumeration value="Afghanistan"/>
>             <xs:enumeration value="Albania"/>
>             <xs:enumeration value="Algeria"/>
>             ...
>         </xs:restriction>
>     </xs:simpleType>
>
>Approach #2 - Express the list using the RELAX NG vocabulary, e.g.,
>
>     <define name="countriesType">
>         <choice>
>             <value>Afghanistan</value>
>             <value>Albania</value>
>             <value>Algeria</value>
>             ...
>         </choice>
>     </define>
>
>Approach #3 - Express the list using a domain-specific vocabulary, e.g.,
>
>     <countries xmlns="http://www.countries.org";>
>
>         <country>Afghanistan</country>
>         <country>Albania</country>
>         <country>Algeria</country>
>         ...
>     </countries>
>
>Approach #4 - Express the list using a "list vocabulary"
>
>(Ken, please correct where I err in my description/analysis)

Thank you.

>In this approach the vocabulary is not customized for a specific 
>list as with approach #3; rather, it is a vocabulary for any list.
>
>Oftentimes when creating a list there are multiple ways to express 
>each value in the list. For example, in a list of countries we may 
>express the first value as Afghanistan or AF. Approach #4 permits 
>each value to be expressed in multiple ways. Thus, the list is 
>expressed in terms of rows and columns - each row has a column for 
>the multiple ways to express a list value.
>
>Here is (a simplified version of) a country list using the 
>genericode vocabulary:

Your example is too simplified because list-level meta data is 
mandatory in every genericode file and your instance does not have 
the required <Identification> element with its required mandatory children.

><gc:CodeList 
>xmlns:gc="http://docs.oasis-open.org/codelist/ns/genericode/1.0/";>
>     <SimpleCodeList>
>         <Row>
>             <Value>
>                 <SimpleValue>AF</SimpleValue>
>             </Value>
>             <Value>
>                 <SimpleValue>AFGHANISTAN</SimpleValue>
>             </Value>
>         </Row>
>         <Row>
>             <Value>
>                 <SimpleValue>AL</SimpleValue>
>             </Value>
>             <Value>
>                 <SimpleValue>ALBANIA</SimpleValue>
>             </Value>
>         </Row>
>         ...
>     </SimpleCodeList>
></gc:CodeList>
>
>An element in an XML instance document can be validated against the 
>list using Schematron in the same manner described in Approach #3.
>
>Approach #4 a standardized list vocabulary that may be used for any list.

True.

>Approach #4 does not enable a list to be used as a building block 
>(data component).

False. (explained below)

>This is because every list has the same namespace.

Which makes all list-processing algorithms and code independent of 
the content, allowing one to leverage a single investment in software 
and access all code lists.  Consider that a single set of genericode 
stylesheets can render all genericode-expressed code lists regardless 
of their content:

   http://www.CraneSoftwrights.com/resources/ubl/index.htm#codess

>Consider a compound document comprised of multiple genericode lists.

Are you speaking of an XML document whose content values are governed 
by values found in multiple genericode lists, or are you speaking of 
one "set of lists" XML document in which there are multiple 
genericode "portions" in the one document?

>Since the lists all have the same namespace an application cannot, 
>say, extract the country list and perform application-specific processing.

Because list-level meta data is mandatory, "application-specific" 
processing of any genericode file knows unambiguously which values 
are in that <SimpleCodeList> element.

An application looking at a suite of genericode files knows not only 
the roles of each set of codes, but the versions, the custodians, and 
other information about each <SimpleCodeList> by its respective 
<Identification> information.

Tony's design is thorough ... genericode can be the basis of 
production-level management of code lists.

>Each of the four approaches has pros and cons so, as always, be sure 
>to understand the alternatives and decide which is best for your situation.

Sounds like sage advice. :{)}

I hope this helps, Roger.

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

--
Upcoming hands-on  XQuery, XSLT, UBL & code list training classes:
Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal