Re: [TED] Abstract Syntax and Abstract-to-Concrete Mappings

> 
> kifer@cs.sunysb.edu (Michael Kifer) writes:
> > 
> > > 
> > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > > 
> > > > Sandro, you are looking in a wrong place. Look at the abstract syntax.
> > > > Instead, you are looking at a translation algorithm!
> > > 
> > > No, I don't think so.
> > > 
> > > Yes, I could have compared the abstract syntax.  In that case I would
> > > have compared what's in the BLD draft...
> > > 
> > >    Equal      ::= 'Equal'
> > >                     '('
> > >                         'side' '->' TERM
> > >                         'side' '->' TERM
> > >                     ')'
> > > 
> > > to some asn07 like this:
> > > 
> > >     class Equal         
> > >         property left: Term
> > >         property right: Term
> > > 
> > > in which case I also have a strong preference for the asn07.
> > 
> > I, on the other hand, do not. 
> 
> I guess that goes on the issues list, then, chairs?    What language to
> use for writing down the abstract syntax -- asn07 or this stylized BNF?
> 
> > With the BNF-like syntax one could even write
> > examples (although a bit awkward), while this cannot be done with asn07.
> 
> It seems like an oxymoron to be able to write down expressions in an
> abstract syntax.   Any syntax you write in is concrete, isn't it?   Of
> course you can generate a concrete syntax like what is above called an
> abstract syntax.

I think this is established practice. For example, in OWL.

> > > But, no, instead I chose to focus on the specification of the mapping
> > > from abstract syntax to presentation syntax.  For that, I quoted the BLD
> > > text which specifies the mapping for Equal and showed it with the a
> > > single line of sbnf which performs the same function.  (The fact that
> > > the text in BLD shows more of how to one might perform that
> > > transformation, instead of *just* specifying it -- that surely accounts
> > > for why it is so much more complicated -- but I don't see that as a
> > > benefit.)
> > 
> > The transformation establishes the relationship between the abstract syntax
> > and the concrete one. One cannot have several syntaxes in the document
> > without telling what the relationship is. 
> 
> Right.  SBNF also establishes that relationship, I believe, and in a
> much more succinct manner.  (I grant that I have not fully specified it.
> I did a first pass explanation and implementation to get some discussion
> going.  The extremely odd reaction has been that the BLD draft has been
> changed to include something quite different.)

We are working against the clock to produce a consistent draft by Friday.
There is not much time and we have to fill in the gaps. We felt that what's
in the draft is not much different from the incomplete proposal that you
advanced. From your reaction it seems that we misunderstood you.
If you produce a more complete one then we can discuss it in the f2f.


	--michael  


>      - s
>    
> > 
> > 	--michael  
> > 
> > > 
> > >      -- Sandro
> > > 
> > > 
> > > 
> > > > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > > > > 
> > > > > > "Sandro Hawke" <sandro@w3.org> wrote:
> > > > > > > 
> > > > > > > "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
> > > > > > > > 
> > > > > > > > Based on the recent discussions, I updated the Abstract Syntax by also
> > > > > > > > just using EBNF and introduced Abstract-to-Concrete Mappings for:
> > > > > > > > 
> > > > > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions
> > > > > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Horn_Rules
> > > > > > > > http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions
> > > > > > > > 
> > > > > > > > Thus, unresolved dependencies on a future metalanguage for defining
> > > > > > > > the RIF Syntax were removed, especially in the Slotted Conditions.
> > > > > > > > This can now contribute to speeding up our editorial BLD WD2 work.
> > > > > > > 
> > > > > > > What's the advantage of this formalism over SBNF?  It seems much more
> > > > > > > complicated to me.
> > > > > > > 
> > > > > > >     - s
> > > > > > 
> > > > > > As far as I can see, this is a slight elaboration (and, perhaps, a visually
> > > > > > more convenient form) of your own proposal of a couple of weeks ago.
> > > > > > Can you explain where do you see the differences?
> > > > > 
> > > > > If you find this:
> > > > > 
> > > > >   class2token('Equal','=')
> > > > >   abs2con4g('Equal'
> > > > >             '('
> > > > >                'side' '->' TERM1
> > > > >                'side' '->' TERM2
> > > > >              ')',
> > > > >           TokenTable)
> > > > >    =
> > > > >     TERM1 lookup('Equal',TokenTable) TERM2
> > > > > 
> > > > > more "visually convenient" than this:
> > > > > 
> > > > >   Equal ::= left::Term '=' right::Term
> > > > > 
> > > > > then I have no idea where to begin this discussion.   
> > > > > 
> > > > > > (Your syntax was at times at odds with the formal syntax, and that has been
> > > > > > fixed. 
> > > > > 
> > > > > I think I was trying to match the BNF not the formal syntax, but that
> > > > > was just for illustration purposes anyway.
> > > > > 
> > > > > > Otherwise, the two seem basically isomorphic to me.)
> > > > > 
> > > > > They appear equalent in some essential ways -- a bit like C++ and
> > > > > assembly are equivalent, I guess.  I have a pretty strong preference for
> > > > > one style over the other.
> > > > > 
> > > > >     -- Sandro
> > > > 
> > > 
> > 
> > 
>

Received on Monday, 10 September 2007 17:12:01 UTC