[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: 4 approaches to structure lists, plus an analysisof ea

• From: Rick Jelliffe <rjelliffe@a...>
• To: "Costello, Roger L." <costello@m...>
• Date: Fri, 20 Feb 2009 02:50:39 +1100

Costello, Roger L. wrote:
> Hi Folks,
>
> 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. 
>   
Why no "Express the list using Schematron?"

  <sch:rule abstract="true" id="countriesType">
       <sch:assert test="
             . = 'Afghanistan'  or
             . = 'Albania' or
            . = 'Algeria'
       ...

Then use it
   <sch:rule context="country">
      <sch:extends rule="countriesType" />
   </sch:rule>

Or the list could be external, and Schematron just looks it up using the 
document() function. It doesn't matter if the list is
marked up as #1, #2, #3, or #4 in that case.
  <sch:rule context="country">
    <sch:let name="theList" 
value="document('something.xml')//rng:define[@name='countriesType']/rng:choice" 
/>
     <sch:assert test="$theList/rng:value[. = current()/.]">
     There current element should have a value found in the list.
   </sch:assert>
  </sch:rule>

Cheers
Rick

> 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)
>
> 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:
>
> <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.
>
> Approach #4 does not enable a list to be used as a building block (data component). This is because every list has the same namespace. Consider a compound document comprised of multiple genericode lists. Since the lists all have the same namespace an application cannot, say, extract the country list and perform application-specific processing. 
>
>
> SUMMARY
>
> 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.
>
> Comments?
>
> /Roger
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>   

• References:
  • 3 approaches to structure lists, plus an analysis of each approach
    • From: "Costello, Roger L." <costello@m...>
  • RE: 4 approaches to structure lists, plus an analysis of eachapproach
    • From: "Costello, Roger L." <costello@m...>