Re: [relax-ng-comment] Abbreviated compact syntax (Re: Compact syntaxis not compact enough. Why?)

["Paul T (spk)" <paul@pault.com>]

> 4. In real-world, non-trivial schemas, references to patterns (written
using
> a bare name) tend to be much more common that element patterns. (For
example
> in the docbook.rng that I use, there are 378 element patterns and 2866 ref
> patterns).   The thing that makes a big difference to the compactness of
> such schemas is the syntax for definitions/references (which is as compact
> as possible in the current syntax) rather than the syntax for element
> patterns.  The current syntax encourages the use of
references/definitions,
> which I think is a good thing.

> Good point, and with proper syntax highlighting in your favorite editor
> the current attribute and element syntax would be easy to spot.

It is a  good point ( complexity of parsing is not relevant to
readability, and I think that  it is readbility which is  a major
concern for  all of us).

I would differentiate between readability of complex
grammars and readability of 'simple' grammars.

In my experience, in case of simple grammars - 80-90% of
'declarations' are  elements / attributes declarations.
That's from statistics I gained working with plenty of
home-grown DTDs, which are used in the real-life projects
right now.  In my experience, the number of entities in
home-grown DTDs is *very* low.  Most of 'homegrown' DTDs
that I'v seen sofar, are close to Eric's example (which started
this thread).

In my oppinion, making element declaration verbose
would not actually encourage the so-called 'typical developer'
to produce a nice DTD, but instead it would result in
'typical developer' producing a 'simple' DTD, just
using a lot of 'element' declarations.

I belive that the 'right' approach with (popular) programming
languages is not to enforce people to become smarter
than they are, but give nice mechanisms  to those who
can use those mechanisms ( are smart already) , but still
make life easy for those, who can/would not use the complex
and nice mechanism.

However, this is minor. Now for the 'real stuff', regarding the
complex grammars.

The major problem for readability of complex grammars that
I had in my life was *not* the way tokens / expressions are "declared"
( would it be written with 'element'  or without  - does not matter, because
as James pointed out, in complex grammars, nonterminals usually win
over terminals ), but the way treminals / nontreminals are *referenced*.

Thats why in  YACC there is/was that de-facto distinction between
'tokens' and 'expressions'

"Objects from the lexer are normally identified in yacc code by character
constants or uppercase names; objects constructed by the parser are usually
identified by lowercase names. This makes it easier to read and understand
the code" (1)

Same thing in C with variables / defines.

When it comes to complex grammars, I *really* like
to see if something is a real 'element',  just by looking
on that 'something', without being forced  to browse
trought the entire grammar to find the declaration of
that 'something'. So the compact syntax of RELAX NG
does solve this problem, but at the cost of 'element'
word! ( Which is not the case in YACC and alikes )

David's notation

<library>
{
  <book>
  {
    @id {text}, @available {text},
    <isbn> {text},
    <title> {@xml:lang {text}, text},
    <author> {@id {text}, <name> {text}, <born> {text}, <dead> {text}?}*,
    <character> {@id {text}, <name> {text}, <born> {text}, <qualification>
{text}}*
  } +
}

perfectly adresses the problem stated above,
with using a subtle roadsigns ( < and > ) to
differentiate  between <element> and 'reference'

RELAX NG addresses the same problem, using the
word 'element' as a roadsign and I think it makes a
mistake, because not a single preceding engine
solves this ('referencing') problem with *that*
kind of solution (introducing special keyword).

<BTW>When I started this thread, I was not realizing that
the real readability problem of complex grammars is
not  how elements are 'declared' but it is how
they are *used*.That's why I now like David's notation
more, than mine. </BTW>

If <element> is confusing, we may
agree on some other roadsign ( like #for_example )
to differentiate between elements and non-elements.

I mean, for example

library
{
  book
  {
    @id { #text }, @available { #text},
    isbn { #text },
    title {@xml:lang {#text}, #text},
    author {@id {#text}, name {#text}, born {#text}, dead {#text}?}*,
    character {@id {#text}, name {#text}, born {#text}, qualification
{#text}}*
  } +
}

Employing the *word* 'element' for the work that
some special character can do (still) seems as an
overkill to me.

Rgds.Paul.

[1] http://www.iosphere.net/~ian/personal/ddj2.htm