- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 09 Mar 2007 09:14:36 +0000
- To: Gerd Wagner <wagnerg@tu-cottbus.de>
- Cc: Chris Welty <cawelty@gmail.com>, 'RIF' <public-rif-wg@w3.org>
Chris Welty wrote: > > > Gerd Wagner wrote: >>> In syntax, you must be concerned with how a sort is defined. In a >>> metamodel, you don't need to represent that (you CAN, of course), but >>> you must represent that a language element has a sort. >> >> No, you need not represent that for constructs for which the >> syntax does not require it. In a rule metamodel a function >> need not have a sort. It will have a sort, though, in the underlying >> vocabulary metamodel (which you still miss to discuss, btw). > > I have no idea what you're talking about. Gerd - I could guess that by "vocabulary" here you might mean "library of builtin functions with their signatures" or you might mean "symbol table of user constants defined within the current scope along with their signatures". Would either of those phrases capture what you mean? If so then I agree, you perfectly well could have those and separate the meta-model corresponding to the syntactic form of a rule from the meta-model corresponding to some internal rule structures. Of course you would need to be careful to use distinct class names. No one is denying you can use a meta-model to convey abstract syntax. I tried to be fairly careful about that in the glossary entry which kicked this thread off. Indeed, as it says there, we agreed to provide a visualization of our syntax in UML notation and have made no decision on which format is normative. The only point is that you can *also* have meta-models designed for other purposes which capture other things than the abstract syntax. Chris' example from ODM (and there are plenty of others) illustrates how a meta-model for a language can be well designed and fit-for-purpose but not correspond directly to the language abstract syntax and so not be useful as a means to automatically generate an appropriate concrete serialization syntax. Thus if someone sits down to review our UML description or to propose alternatives they should keep firmly in mind that the purpose is to represent an abstract syntax and not anything else. [The issue of ans06 v. km3 is orthogonal and I was careful to reference your email on km3 alongside the asn06 pointers.] Dave
Received on Friday, 9 March 2007 09:14:44 UTC