[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC