Re: [xml-dev] 3 possible approaches for representing concepts

[Bill de hÓra <bill@dehora.net>]

John Cowan wrote:
> Chiusano Joseph scripsit:
> 
> 
>>Yes - all great points (thank you to everyone!). I also think that one
>>disadvantage to approaches #2 and #3 (from the original e-mail - these
>>approaches used attributes) is that using purely W3C Schema, it is not
>>possible to enforce mandatory/optional if, given the value of the
>>attributes, the entire "set" (element/attributes/values) may be
>>considered mandatory in some cases, but optional in others (according to
>>the data requirements.
> 
> 
> So much the worse for WXS, to be sure.  RNG screams through this kind of
> co-occurrence constraints.  A nice simple example is requiring that
> country="US" coexist with state="xx" where xx is a valid state code, and
> country="CA" coexist with province="xx" where xx is a valid province code.

Real world example of what John and Joe are talking about. We have 
to accept some address markup, but the producer can't validate it on 
the way out (precisely because there's a co-occurence and they're 
using a schema that doesn't handle such things).

So we want these to be valid:

   <Address
   Type="Residential"
   Line1="270 St. Teresas Gardens"
   Line2="Dolphins Barn"
   Country="UK"
   CountryText="United Kingdom"/>

   <Address
   Type="Residential"
   Line1="270 St. Teresas Gardens"
   Line2="Dolphins Barn"
   County="D08"
   CountyText="Dublin 8"
   Country="IE"
   CountryText="Ireland"/>

And these invalid:

   <Address
   Type="Residential"
   Line1="270 St. Teresas Gardens"
   Line2="Dolphins Barn"
   County="D08"
   CountyText="Dublin 8"
   Country="UK"
   CountryText="United Kingdom"/>

   <Address
   Type="Residential"
   Line1="270 St. Teresas Gardens"
   Line2="Dolphins Barn"
   Country="IE"
   CountryText="Ireland"/>

On our side we'll use something like this to trap junk data:

   <?xml version="1.0"?>
   <grammar
   xmlns="http://relaxng.org/ns/structure/1.0";>
   <start>
     <ref name="Address"/>
   </start>
   <define name="Address">
     <element name="Address" >
       <attribute name="Type">
         <text/>
       </attribute>
       <attribute name="Line1">
         <text/>
       </attribute>
       <optional>
         <attribute name="Line2">
           <text/>
         </attribute>
       </optional>
       <optional>
         <attribute name="Line3">
           <text/>
         </attribute>
       </optional>
       <optional>
         <attribute name="Line4">
           <text/>
         </attribute>
       </optional>
       <choice>
         <group>
           <attribute name="County">
             <text/>
           </attribute>
           <attribute name="CountyText">
             <text/>
           </attribute>
           <attribute name="Country">
             <value>IE</value>
           </attribute>
           <attribute name="CountryText">
             <value>Ireland</value>
           </attribute>
         </group>
         <group>
           <choice>
             <group>
               <attribute name="Country">
                 <value>UK</value>
               </attribute>
               <attribute name="CountryText">
                 <value>United Kingdom</value>
               </attribute>
             </group>
             <!-- other valid code combinations --->
           </choice>
         </group>
       </choice>
       <empty/>
     </element>
    </define>
    </grammar>

The only remaining matter is how to manage the value enumerations.

The main benefit of being able to express co-occurence constraints 
in a schema language is not to be able say cool things with markup, 
talk about the formal properties, or even point fingers at other 
schema languages. It's the eliminatation of defensive code, which is 
invariably brittle, error-prone and time consuming.

Bill de hÓra
--
Propylon
www.propylon.com