[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Alternative algorithm to restrict use of data/string in patterns.
> > If calcFPDS can be made to the unary function, then what will be > > calcFPDS(<attribute/>) and calcFPDS(<empty/>)? > > I think you would return "element", since "element"|X = X for any X. I still think calcFPDS cannot be an unary function. Consider checking the following pattern (with calcFPDS', which is the unary version of calcFPDS) <oneOrMore> <group id="g1"> <string>abc</string> <group id="g2"> <element /> <group id="g3"> <string>def</string> <empty /> </group> </group> </group> </oneOrMore> check( <oneOrMore> ....... </oneOrMore>, "element" ) => check( <group id=g1> ... </group>, calcFPDS'( <oneOrMore>...</oneOrMore> ) => check( <group id=g1> ... </group>, "text" ) => check( <group id=g2> <element/> <group id=g3/> </group>, "text" ) & check( <string>abc</string>, calcFPDS( <group id=g2 /> ) ) consider the first check => check( <group id=g3> <string/> <empty/> </group>, "text" ) & check( <element/>, calcFPDS(<group id=g3 />) ) again consider the first one => check( <empty/>, "text") & check( <string>def</string>, calcFPDS(<empty/>) ) consider the second check. According to your suggestion, calcFPDS(<empty/>) is "element". => check( <string>def</string>, "element" ) => OK So it can't detect that the pattern is illegal. However, the pattern is actually illegal because it is equivalent to <oneOrMore> <string>abc</string> <element /> <string>def</string> </oneOrMore> -- Kohsuke KAWAGUCHI +1 650 786 0721 Sun Microsystems kohsuke.kawaguchi@eng.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC