OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]