• From: Rick Marshall <rjm@z...>
• To: Mukul Gandhi <gandhi.mukul@g...>
• Date: Wed, 13 Dec 2006 08:07:18 +1100

I like this one too and it has the advantage that more terms can be 
easily added eg:

<?xml version="1.0"?>
<op:or xmlns:op="http://operator-ns">
  <op:and>
     <a/>
     <b/>
    <d/>
  </op:and>
  <c/>
    <op:and>
    <a/>
    <f/>
    </op:and>
</op:or>

<!-- (a and b and d) or c or (a and f) -->
etc

now can we write an xslt that understands "and" and "or" and optimises 
the dom parsing like a good compiler or interpreter would ...

Rick

Mukul Gandhi wrote:
> The first approach looks good to me. But perhaps assigning a namespace
> to operator elements could be a good idea (something like below).
>
> <?xml version="1.0"?>
> <op:or xmlns:op="http://operator-ns">
>   <op:and>
>      <a/>
>      <b/>
>   </op:and>
>   <c/>
> </op:or>
>
> On 12/12/06, Andrew Welch <andrew.j.welch@g...> wrote:
>> I've just had to design some XML to model items that can have "and"
>> and "or" relationships between each one.
>>
>> For example:
>>
>> (a and b) or c
>>
>> could be designed as:
>>
>> <or>
>>    <a>
>>    <and>
>>        <b/>
>>        <c/>
>>    </and>
>> </or>
>>
>> another option could be to rely on position:
>>
>> <a>
>> <and/>
>> <b/>
>> <or/>
>> <c/>
>>
>> and another could be model the relationships separately somehow:
>>
>> <relationships>
>>  <rel ref="r1" type="and">
>>    <ent id="a"/>
>>    <ent id="b"/>
>>  </rel>
>>  <rel ref="r2" type="or">
>>    <ent id="r1"/>
>>    <ent id="c"/>
>>  </rel>
>> </relationships>
>> <a id="a"/>
>> <b id="b"/>
>> <c id="c"/>
>>
>> Each has its own advantages/drawbacks.  Personally I like the first
>> technique, although it can get cluttered when there are 10+ items.
>>
>> Are there any better ways that I'm missing?
>>
>> cheers
>> andrew
>
>

• References:
  • XML design of ((a and b) or c)
    • From: "Andrew Welch" <andrew.j.welch@g...>
  • Re: XML design of ((a and b) or c)
    • From: "Mukul Gandhi" <gandhi.mukul@g...>