Re: [relax-ng] A mechanism for handling inclusion/exclusion

["David RR Webber" <david@drrw.info>]

James,

The way we've approached this in CAM is to make it declarative.

I think this significantly enhances the readability.  It would be nice
if CAM and RELAX both had the same approach here.

The context examples discussed so far have been extremely difficult to
comprehend IMHO - unless you happen to be a Math honours
grad' ; -)

Essentially in the CAM approach you have a <context> section,
and inside that you declare the instances of the rules.
That way you can have sets of rules driven off context factors.

You should typically have a <default> context - that applies
when no other rules are triggered / specified - and then we use
XPath to provide expressions for the rule blocks themselves.

Here's an example:

<BusinessUseContext>
 <Rules>
   <default>
     <context> <!-- default structure constraints -->
      <constraint
action="makeRepeatable(//CentralAccountingMasterfile/TreasuryCode)" />
      <constraint
action="makeMandatory(//CentralAccountingMasterfile/TreasuryCode)" />
      <constraint
action="makeMandatory(//CentralAccountingMasterfile@Citation)" />
      <constraint
action="makeMandatory(//CentralAccountingMasterfile@ContentVersion)" />
      <constraint action="makeOptional(//TransferFromDepartmentCode)" />
      <constraint action="makeOptional(//SubClass)" />
      <constraint action="makeOptional(//SubAccountSymbol)" />
      <constraint
action="makeOptional(//DispersingExtendedFiscalYearCancelled)" />
     </context>
   </default>
   <context condition="token='//TransferFromDepartmentCode' and
       greaterthan(value,'00')">
     <constraint action="makeMandatory(//MainAccount)"/>
     <constraint action="makeMandatory(//SubClass)"/>
     <constraint action="makeMandatory(//SubAccountSymbol)"/>
     <constraint
action="makeMandatory(//DisbusingExtendedFiscalYearCancelled)"/>
   </context>
</Rules>
</BusinessUseContext>

Thanks, DW.

----- Original Message ----- 
From: "James Clark" <jjc@jclark.com>
To: "MURATA Makoto" <EB2M-MRT@asahi-net.or.jp>
Cc: <relax-ng@lists.oasis-open.org>
Sent: Sunday, October 12, 2003 11:34 PM
Subject: Re: [relax-ng] A mechanism for handling inclusion/exclusion


>
> > Suppose that we want to disallow <a>, <em>, and <span> to have
> > immediate or non-immediate subordinate <a>, <em>, and <span>,
> > respectively.  A schema (in the compact syntax) for this constraint is
> > shown below:
>
> > a =
> >   element a {
> >     mixed{
> >       (([not(ancestor::em)], em) | ([not(ancestor::span)], span))*
> >     }
> >   }
> >
> > span =
> >   element span {
> >     mixed{
> >       (([not(ancestor::a)], a) | ([not(ancestor::em)], em))*
> >     }
> >   }
> >
> > em =
> >   element em {
> >     mixed{
> >       (([not(ancestor::span)], span) | ([not(ancestor::a)], a))*
> >     }
> >   }
>
> I think it's a little confusing to have context be handled as a new kind
> of pattern.  Would it be possible instead to handle it in the
> name-class?  Your example might be written instead as:
>
> a = element a - a//a { mixed { (em|span)* } }
> span = element span - span//span { mixed { (a|em)* } }
> em = element em - em//em { mixed { (span|a)* } }
>
> James
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/relax-ng/members/leave_workgroup.php.
>
>