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: [relax-ng] Agenda RELAX NG telcon 25th April

I would like us to try to make decisions on some of the compact syntax
issues this week.

1. \x{N} escapes.  Current sentiment is to allow these everywhere.


(I was able to implement this within the framework of JavaCC.)

2. Long string literals. Current sentiment is to allow multiple adjacent
string literals wherever a single string literal is allowed.  Doubling of a
"/' in a "/' delimited string is not supported.  Instead, if a user needs a
string containing both ' and ", they split it into multiple consecutive
string literals, none of which contain both ' and ".


The grammatical ambiguity that this causes can be resolved with prose that
either says that adds literal concatenation as an additional translation
phase between tokenization and parsing, or that specifies that reduce/reduce
conflicts are resolved in favour of string literal concatenation. (I've
implemented this and it's easy.)

3. Newlines in strings.  If we were to disallow literal newlines in strings,
then we would need some extra mechanism to get newlines into strings.  I
haven't been able to come up with anything I like and nobody else has
proposed anything, so I propose that we decide this issue by continuing to
allow literal newlines in strings.

4. div syntax. I propose

  div { }

since this works well with ## and requires no special grammatical hacks.
(I've implemented this and it's easy.)


5. ## syntax. I propose we allow this and put it in the grammar (i.e. a
comment starts with a # followed by anything other than a #).  I propose no
special ## syntax for a:documentation on the implicit top-level grammar.
Instead if a:documentation is needed, make the implicit top-level grammar
explicit. See


6. Encoding declaration and detection.  Current sentiment seems against any
special encoding declaration mechanism for our syntax.  A strawman proposal
is here:



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC