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

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

Sean,

It's a good point - the slope is slippery.

CAM has adopted the schematron style approach
and is designed to be used as you say as a
next stage in the process.

In that respect its a good compliment to both
Relax and XSD to handle business process requirements.

Thanks, DW

Quoting Sean McGrath <sean.mcgrath@propylon.com>:

> James,
> 
> Is this crossing the rubicon into rules based validation ala Schematron?
> 
> In my own efforts, I regularly leave inclusion/exclusion to a separate
> pass in a pipeline processing model and find it works well and retains
> simplicity through divide and conquer.
> 
> I'm totally out of the loop, but couldn't inclusion/exclusion be looked upon
> through DSDL shaped eyes?
> 
> I think it is interesting to consider how you could lay out a validation as 
> a series of
> notional passes, using a mixture of notations for grammars, rules etc. and 
> yet, through
> some comp. sci. magic (perhaps Jackson Inversion), perform all stages in a 
> single
> actual pass through the parse tree.
> 
> Sean
> 
> 
> >----- 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.
> > >
> > >
> >
> >
> >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.
> 
> http://seanmcgrath.blogspot.com
> 
> 
> 
> 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.
> 
> 


http://drrw.net