> > - Just as adjacent patterns or name classes in a group require a
connector
> > (e.g. |), so annotation elements that are siblings of patterns or name
> > classes require a connector (>)
>
> I think that ">>" should be used instead of ">" (as in the previous
> representation), because of its greater visibility.
Noted. Anybody else have an opinion?
> > - There's one case where an arbitrary amount of lookahead is required:
in
> > order to determine whether a file contains a sequence of definitions or
a
> > pattern, you may have to lookahead past an annotation in square
brackets,
> > which can consist of arbitrarily many tokens (however, this is easily
> > implementable in JavaCC without hackery)
>
> This may be heresy, but it would be all right with me if the pattern
> version wasn't represented in the non-XML syntax: any file containing
> just a pattern can be prefixed with "start =" with no effect on
> semantics.
It does change the semantics in one (admittedly strange) case.
Suppose we have foo.rnx:
start = externalRef "bar.rnx"
x = text
bar.rnx:
element foo { x }
Changing bar.rnx to
start = element foo { x }
changes the semantics
> > The non-XML syntax cannot represent the div element.
>
> I continue to think that a bare curly-braces-block should be mapped
> to div. Some work would be needed after a datatype name and after
> include, which are (?) the only places that make a block optional.
The problem as you observe is the optional block.
I coincidentally had a flash of inspiration on this. With the new
annotation syntax, we can simply require the annotation (in square brackets)
before the div. There's no point in having a div without any annotations, so
this is no inconvenience. There's no formal loss of expressiveness because
the pointless case of a div with no annotations can be handled by an
(equally pointless) empty pair of square brackets. This resolves the
ambiguity because we cannot have annotations between the include/datatype
name and the optional block.
James
