OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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