Subject: Re: Alternative algorithm to restrict use of data/string in patterns.
> Let me propose another possibility. Allow me to write in a formal > manner. Sorry, I don't understand this description. Could you state your restriction in a similar way to Kawaguchi-san's and mine? Does your restriction allow anything that mine doesn't? Could you give an example of things that your restriction disallows that mine does not? Support for <list> makes a big difference here. It means that we need to consider patterns as matching against sequences of *strings* and elements, not sequences characters and elements. This means that a pattern such as: <element name="foo"><data type="int"/><data type="int"/></element> which previously had semantics which were very hard to implement, now has well-defined semantics that are very easy to implement: it won't match anything, because <data> matches a single string and an <element> never has two consecutive string children. So this problem now becomes one of detecting a certain class of impossible patterns. With this perspective, one could even argue that a restriction is no longer necessary. With the new semantics, a case such as: <element name="bar"> <interleave> <zeroOrMore> <data type="int"/> </zeroOrMore> <zeroOrMore> <element name="foo"/> </zeroOrMore> </interleave> </element> becomes interesting; it is possible for it to match an element, yet me might want to disallow it. James
Powered by eList eXpress LLC