Re: sbnf (striped BNF)

the requirement is to have both a linear presentation syntax and an XML 
schema-specified syntax, both with a common abstract syntax and semantics.

one approach is to just write down the 2 syntaxes, one in BNF and the 
other in XML schema, and verify by hand that they are the same at an 
abstract level.

a second approach is to write down the abstract syntax in some formal 
notation and use software to generate the presentation syntax and the 
XML schema.

a third approach is to write down the presentation syntax in some formal 
notation and use software to generate the XML schema.
BNF might work, but you have to show how to generate a "usable" XML 
schema from a BNF description.

Michael Kifer wrote:
>> kifer@cs.sunysb.edu (Michael Kifer) writes:
>>     
>>> Why do you think that this move has not been well-received? 
>>>       
>> Because the only public comment I got was from Harold and it was still
>> advocating top-down (ASN-first) design.  I got one very negative private
>> comment (also strongly advocating top-down ASN-first design).
>>     
>
> I did not understand Harold's comment this way. It seems to me that he just
> wanted to slightly modify your new proposal.
>
>   
>>> For instance, I
>>> did not respond, but I always thought that BNF is the way to
>>> go. 
>>>       
>> Yes, but that doesn't mean you support SBNF.  I can't really tell.
>>     
>
> I think this is definitely an improvement over the previous ASN attempts.
>
>
>   
>>> Introducing new notation and doing research on it as we go does not
>>> look like what we should be doing.
>>>       
>> If there were something off-the-shelf that would solve our problems,
>>     
>
> What are our problems exactly? BNF was fine for over 40 years and I cannot
> understand why it is no longer adequate all of a sudden.
>
>   
>> that would be great.  Maybe there is, but no one seems able to lead us
>> to it and help us with it.  I'm doing the best I can in the absense of
>> other options.
>>
>>     
>>>> In any case, I think I'd want machine-readable data in each dialect
>>>> definition which told my software which collections were ordered and
>>>> which were unordered.
>>>>         
>>> f(a->b,c->d) is not a collection. It is a term. Do you also want to be able
>>> to express in the syntax that p/\q == q/\p?
>>> What about p/\(q\/r) == p/\q \/ p/\r?
>>>
>>> It beats me why do you want to capture some part of the semantics in the
>>> definition of the syntax.
>>>       
>> I don't think we're going to get anywhere with this discussion.
>>     
>
> We could get to a resolution, if you could explain which problems you are
> trying to solve. It seems that you think that I am pulling your leg, but in
> reality I am honestly trying to understand what the problem is.
>
>   
>> It makes perfect sense to me that we'd think of the rules in a ruleset
>> as being in an unordered collection and the arguments in an argument
>> list being in an ordered collection.  I understand the semantics will be
>> expressed against the presentaiton syntax, and that's fine, but I think
>> at least some of us implementing translators will have a much easier
>> time thinking at the data-model level.
>>     
>
> I really doubt that embedding this piece of semantic into syntax is going
> to help anybody implement anything. At least, this was not my experience.
>
>
> 	--michael  
>
>
>   
>>      -- Sandro
>>
>>
>>     
>
>
>
>

Received on Friday, 7 September 2007 04:44:39 UTC