Re: Alternative algorithm to restrict use of data/string in patterns.

[James Clark <jjc@jclark.com>]

> 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