[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [relax-ng] A mechanism for handling inclusion/exclusion
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]