[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [relax-ng] Annotations in the non-XML syntax
> > - 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC