- From: Sandro Hawke <sandro@w3.org>
- Date: Mon, 13 Nov 2006 14:23:17 -0500
- To: kifer@cs.sunysb.edu (Michael Kifer)
- Cc: public-rif-wg@w3.org
> > I guess it's mostly an issue of software engineering practice. > > > > The BNF is like a data structure where most of the fields are not named. > > That's probably okay as long as the grammar (or data structure, if > > you're thinking about it before it's serialized [marshalled] or after > > it's unserialized [unmarshalled]) is small and simple, as in the core. > > > > But when I start to think about all the ways the grammar will be added > > to by various extensions, I am reminded about how as projects grow it's > > important for the underlying data structures to be very easy to > > understand. I want all the parts to be named, at least, and probably > > each part should have it's own documentation. > > > > Does that help explain the motivation? I also think it'll be important, > > when we're designing the serialization style, for that work be isolated > > by a good interface from the discussions about the abstract language. > > I think what you are trying to define is an ontology for rule parts > (or maybe a UML-like diagram). This is fine and useful, but I don't think > it is a substitute for a concise BNF. I don't think either one substitutes for the other, exactly, but I think the BNF introduces a lot of details (like term ordering, keywords, and punctuation) which need to vary from one concrete syntax to another, and which are generally irrelevant for an XML syntax. I think an asn06 syntax lets the WG proceed without getting stuck on details of a concrete syntax. To be specific: would you propose that the First Public Working Draft of the RIF Specification include a plain-text concrete syntax for rules? We don't have consensus in the WG on such a syntax or on whether we should standardize one. > Also, I don't agree that BNF's parts > are unnamed. They look perfectly named to me (by nonterminals). The classes are named, but not the properties/roles. Like in this part of the grammar [1]: HEAD ::= LITFORM BODY ::= CONDIT Implies ::= HEAD ':-' BODY we see a very clever hack, introducing a special kind of non-terminal (distinguished by being all upper case and implemented in the DTD as XML Entities instead of grammar productions). This is a common pattern in modeling, where class names and role names are the same ("my mother is an instance of class 'Mother', my friend is an instance of class 'Friend'), but I think it quickly turns into an anti-pattern and muddies the waters. I find the formulation Implies head: LitForm body: Condit makes it much more clear that "head" and "body" name the roles that the parts of the implication statement play. Personally, I'd probably change the names to be closer to what I see in logic books (and CommonLogic): ImplicationSentence if: Sentence then: AtomicSentence but that's a different issue. -- Sandro [1] http://www.w3.org/2005/rules/wg/wiki/B.1_Horn_Rules
Received on Monday, 13 November 2006 19:23:37 UTC