This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Proposal for BNF/EBNF markup
At 09:40 AM 3/22/00 -0500, Dave Makower wrote:
(1) It seems to me that the element names are a little cryptic, especially
if they're going to find their way into the DocBook lexicon, appearing
alongside other elements not related to BNF/EBNF. One of the things I like
about DocBook is that I can usually do a quick browse of the element
reference and find what I'm looking for by a couple of quick intuitive
guesses. (There are exceptions, but I guess the intention is to avoid
making this one of them.) What would you think about making the element
names a little more self-explanatory, at the risk of making them too
verbose. For example:
>prod --> production
I can see this, especially since it's at a kind of top level.
>lhs --> prodleftside
>rhs --> prodtranslation
> (or maybe translation, translations, or translationlist)
These are traditionally called lhs and rhs in all kinds of computer science
contexts, so I'm reluctant to expand them. If we do, it should be
lefthandside and righthandside.
>nt --> nonterminal
Sure, if others agree.
>rhsline --> prodtranslationitem (or maybe translationitem)
As I just explained in another posting, I wasn't clear enough about the
purpose of rhsline. It has no production-specific meaning; it's just
presentational. So I think we should instead just use DocBook's sbr and
get it over with. :-)
>(2) I've seen repetition expressed using * and +, and I've also seen it
>expressed using curly brackets. What would you think if this were
>expressed semantically in the XML with something like either a
><bnfrepetition> element (which begs the question, how to distinguish
>between * and +), or perhaps a <zeroormore> and a <oneormore>
>element. (Note: I'm not thrilled with my element names here; I'm more
>interested in bringing up the idea to encourage feedback.)
Yikes... I fear that this will tip the design over to doing actual
modeling, which I've tried to do in the past and which rarely satisfies
everybody. I had this discussion with the XML specification editors, and
we ended up agreeing that it was more trouble than it was worth, and made
the markup really complicated. Are there requirements here for being able
to switch representations of the same BNF? to query on the presence of a
certain occurrence indicator?
If folks can send their feedback over the next couple of days, I can put
together a revised proposal by Monday.
Eve
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center elm @ east.sun.com