Issue 12367: Issue against QVT ptc/07-07-07 : relational grammar (qvt-rtf)
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity: 
Summary: Section 7.13.5 Relation BNF


The grammar rule for template is incorrect (It does not allow a 
template to have embedded within it another template. The example in 
Appendix A will not compile with such a grammar.)


It says:


<propertyTemplate> ::= <identifier> '=' <OclExpressionCS>


It should says:
<propertyTemplate> ::= <identifier> '=' ( <template> | 
<oclExpressionCS
Resolution: 
Revised Text: 
Actions taken:
April 3, 2008: received issue
July 15, 2014: closed issue
Discussion: 
No. The grammar also redefines:
<OclExpressionCS> ::= <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> |
<LetExpCS> | <IfExpCS> | '(' <OclExpressionCS> ')' | <template>
Disposition: Closed, No Change
End of Annotations:=====
ilScanner-Watermark: 1207852162.28563@QERYiLy4b0F3Q6aUFvZxUQ
From: Peter Denno <peter.denno@nist.gov>
Organization: NIST
To: issues@omg.org
Subject: Issue against QVT ptc/07-07-07 : relational grammar
Date: Thu, 3 Apr 2008 14:28:59 -0400
User-Agent: KMail/1.9.1
X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information
X-MailScanner-ID: m33ITKSl009527
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: 
X-MailScanner-From: peter.denno@nist.gov
X-Spam-Status: No





Section 7.13.5 Relation BNF


The grammar rule for template is incorrect (It does not allow a 
template to have embedded within it another template. The example in 
Appendix A will not compile with such a grammar.)


It says:


<propertyTemplate> ::= <identifier> '=' <OclExpressionCS>


It should says:
<propertyTemplate> ::= <identifier> '=' ( <template> | 
<oclExpressionCS> ) 


--
Best regards,


From: "Willink, Ed" <Ed.Willink@thalesgroup.com>
To: "'Peter Denno'" <peter.denno@nist.gov>
Cc: qvt-rtf@omg.org
Subject: RE: issue 12367 -- QVT RTF issue
Date: Mon, 7 Apr 2008 19:04:16 +0100 
X-Mailer: Internet Mail Service (5.5.2656.59)


Hi Peter


I'm not the author, but I'm prepared to defend the QVTr grammar anyway.


The expression of a grammar is a compromise between semantic precision
and a combinatorial complexity explosion.


A grammar generally tolerates a larger language (allows invalid constructs)
and then relies on a set of semantic constraints to reduce the
larger language.


For instance, it is impractical with standard parsers to write a grammar
that prohibits duplicate definitions, since the parser stack maintains
only a branch rather than a tree of context.
Detection of duplicates is therefore imposed as a constraint during a
semantic analysis phase that follows lexical and syntactic analysis.


With QVTr and QVTc (and perhaps QVTo) extending EssentialOCL it is
a pragmatic convenience to just extend OclExpressionCS, since some
usages of OclExpressionCS do need extending. The extension must be
named OclExpressionCS to ensure that OCL is extended. (Many parser
tools and EBNF allow this form of extension.)
This unfortunately extends more than is really necessary, so there
is a case for providing more restrictive extensions where possible,
but that could complicate the grammar.
Philosophically this is no different to an existing OCL grammar failing
to adequately identify a BooleanExpression as a syntactically distinct
concept from an arbitrary expression..


The above justifies the syntactical exposition of the grammar.
I will not attempt to justify the semantic exposition, which I
feel is a major shortcoming in QVT 1.0 (already raised as an Issue.)


"OMG Issue No:10646: Missing explanations in BNF
Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com
ed@willink.me.uk)
Summary:
The OCL 2.0 spec has a 32 page section on concrete semantics.
QVTr has 1.5 pages of BNF but no explanation.
In particular:
What are the semantics of 'import' which has no abstract counterpart?
Where is the explanation of the role of [ '{' '}' ] in a ?
Where is the instruction on how to treat the "_" identifier?
Resolution: Deferred
Comment:
Specifying more formally the mapping between the concrete syntax and the
metamodel -
as it was achieved for the OCL language - could be interesting. However it
is a very time
expensive task. Also, may be difficult to maintain. We prefer defer such
decision to a
future RTF."


        Regards


                Ed Willink


*******************************************************************************
Please consider the environment before printing this email.
*******************************************************************************
This email and any files transmitted with it are intended solely for the use of
the individual or entity to whom they are addressed and may not be divulged to
any third party without the express permission of the originator.  Any views
expressed in this message are those of the individual sender, except where the
sender specifically states them to be the views of Thales Research & Technology
(UK) Limited.
******************************************************************************* 

X-MailScanner-Watermark: 1208201950.82236@91XO/w7RlXtZkIoLkHlGAw
From: Peter Denno <peter.denno@nist.gov>
Organization: NIST
To: "Willink, Ed" <Ed.Willink@thalesgroup.com>
Subject: Re: issue 12367 -- QVT RTF issue
Date: Mon, 7 Apr 2008 15:38:07 -0400
User-Agent: KMail/1.9.1
Cc: qvt-rtf@omg.org
X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information
X-MailScanner-ID: m37JdAxY011415
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: 
X-MailScanner-From: peter.denno@nist.gov
X-Spam-Status: No


On Monday 07 April 2008 14:04, Willink, Ed wrote:
> Hi Peter
>
> I'm not the author, but I'm prepared to defend the QVTr grammar
> anyway.
>
> The expression of a grammar is a compromise between semantic
> precision and a combinatorial complexity explosion.


Hi Ed,


I'm not sure I agree with that. For most computer languages, the 
grammar tells you the space of legal sentences. Some of those 
sentences might not be valid on the target machine, but they all are 
subject to further processing, resulting in instructions to the 
target machine.


You are saying this isn't true of QVT. If what you say is necessarily 
the case, then I guess we implementers would just pay the price by 
developing more complex tools. Writers of the specification would pay 
the price by laboring to describe what those additional constraints 
are (something the QVT writers ought to now do, if they aren't 
willing fix things). And readers of the spec would pay the price of 
having to read through all that extra stuff. 


I have a grammar that I think works for what is intended. My fledgling 
tool at least compiles and runs the RDBMS example in Annex A. Maybe 
you could tell me what is wrong with the production I'm suggesting, 
and we can work from there. 


I wrote the grammar of the ISO EXPRESS-X mapping language. So this 
work isn't new to me.


> A grammar generally tolerates a larger language (allows invalid
> constructs) and then relies on a set of semantic constraints to
> reduce the larger language.
>
> For instance, it is impractical with standard parsers to write a
> grammar that prohibits duplicate definitions, since the parser
> stack maintains only a branch rather than a tree of context.
> Detection of duplicates is therefore imposed as a constraint during
> a semantic analysis phase that follows lexical and syntactic
> analysis.
>
> With QVTr and QVTc (and perhaps QVTo) extending EssentialOCL it is
> a pragmatic convenience to just extend OclExpressionCS, since some
> usages of OclExpressionCS do need extending. The extension must be
> named OclExpressionCS to ensure that OCL is extended. (Many parser
> tools and EBNF allow this form of extension.)


If, like me, you already have an OCL tool that is used separate from 
this QVT work, you don't want to extend the OCL grammar. I think you 
are making some unnecessary assumptions about the tooling. 


Keep the specifications separate, and make the references to the OCL 
spec as clear as possible.


> This unfortunately extends more than is really necessary, so there
> is a case for providing more restrictive extensions where possible,
> but that could complicate the grammar.


We should be willing to make the grammar reflect what is intended. If 
that takes twice the number of productions the spec now has (I doubt 
that) would that make it too complicated? For tools? For human 
readers?


> Philosophically this is no different to an existing OCL grammar
> failing to adequately identify a BooleanExpression as a
> syntactically distinct concept from an arbitrary expression..


Quite a bit different IMO. What you describe concerns tracing types 
through expression syntax -- performed as analysis of the parse. 
That's hard. What we are talking about with respect to 
OCLExpressionCS is just a matter of generating error messages because 
we didn't bother to say that e.g. a template can't be the body of a 
when clause. (If that's what QVT intends. I don't see the answer in 
the spec.)


> The above justifies the syntactical exposition of the grammar.
> I will not attempt to justify the semantic exposition, which I
> feel is a major shortcoming in QVT 1.0 (already raised as an
> Issue.)


Probably more than '*an* issue' ;^)


> "OMG Issue No:10646: Missing explanations in BNF
> Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com
> ed@willink.me.uk)
> Summary:
> The OCL 2.0 spec has a 32 page section on concrete semantics.
> QVTr has 1.5 pages of BNF but no explanation.
> In particular:
> What are the semantics of 'import' which has no abstract
> counterpart? Where is the explanation of the role of [ '{' '}' ] in
> a ? Where is the instruction on how to treat the "_" identifier?
> Resolution: Deferred
> Comment:
> Specifying more formally the mapping between the concrete syntax
> and the metamodel -
> as it was achieved for the OCL language - could be interesting.
> However it is a very time
> expensive task. Also, may be difficult to maintain. We prefer defer
> such decision to a
> future RTF."
>
>       Regards
>
>               Ed Willink
>
> *******************************************************************
>************ Please consider the environment before printing this
> email.
> *******************************************************************
>************ This email and any files transmitted with it are
> intended solely for the use of the individual or entity to whom
> they are addressed and may not be divulged to any third party
> without the express permission of the originator.  Any views
> expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Thales Research & Technology (UK) Limited.
> *******************************************************************
>************


-- 
Best regards,
  - Peter 



X-MailScanner-Watermark: 1208174527.74671@KEwwJQZbwt2XAENmAjwziw
From: Peter Denno <peter.denno@nist.gov>
Organization: NIST
To: "Willink, Ed" <Ed.Willink@thalesgroup.com>
Subject: Re: issue 12367 -- QVT RTF issue
Date: Mon, 7 Apr 2008 08:01:03 -0400
User-Agent: KMail/1.9.1
Cc: qvt-rtf@omg.org
X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information
X-MailScanner-ID: m37C23Bs015071
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: 
X-MailScanner-From: peter.denno@nist.gov
X-Spam-Status: No


On Friday 04 April 2008 02:48, Willink, Ed wrote:
> Hi Peter
>
> This change is not necessary since 7.13.6 extends OclExpressionCS
> to include template.
>
> <OclExpressionCS> ::= <PropertyCallExpCS> | <VariableExpCS> |
> <LiteralExpCS>
>
> | <LetExpCS> | <IfExpCS> | '(' <OclExpressionCS> ')' | <template>



Hi Ed, 


I think there are two problems with this solution:


(1) This production should not be called OclExpressionCS, since that 
is already something in OCL. The QVT grammar elsewhere (properly) 
uses OCL production LHS terms to refer to things in the  OCL 
specification. This breaks the rule.


And more importantly, 


(2) This then allows <template> grammar in <when> <where> and 
<assignmentExp> productions. (I suspect that the OCL definition of 
OCLExpressionCS, or something trimmed down from it, is what is 
intended in those productions). 


        
>
>     Regards
>
>         Ed Willink
>
>
>   _____
>
> From: Juergen Boldt [mailto:juergen@omg.org]
> Sent: 03 April 2008 20:34
> To: issues@omg.org; qvt-rtf@omg.org
> Subject: issue 12367 -- QVT RTF issue
>
>
> This is issue #12367    From: Peter Denno <peter.denno@nist.gov>
>
> Issue against QVT ptc/07-07-07 : relational grammar
>
> Section 7.13.5 Relation BNF
>
>
> The grammar rule for template is incorrect (It does not allow a
> template to have embedded within it another template. The example
> in Appendix A will not compile with such a grammar.)
>
>
> It says:
>
>
> <propertyTemplate> ::= <identifier> '=' <OclExpressionCS>
>
>
> It should says:
> <propertyTemplate> ::= <identifier> '=' ( <template> |
> <oclExpressionCS
>
>
> Juergen Boldt
> Director, Member Services
> Object Management Group
> 140 Kendrick St
> Building A Suite 300
> Needham, MA 02494
> USA
>
> tel: +1 781 444 0404 x 132
> fax: +1 781 444 0320
> email: juergen@omg.org
> www.omg.org <http://www.omg.org/>
>
>
>
> *******************************************************************
>************ Please consider the environment before printing this
> email.
> *******************************************************************
>************ This email and any files transmitted with it are
> intended solely for the use of the individual or entity to whom
> they are addressed and may not be divulged to any third party
> without the express permission of the originator.  Any views
> expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Thales Research & Technology (UK) Limited.
> *******************************************************************
>************


-- 
Best regards,
  - Peter 




From: "Willink, Ed" <Ed.Willink@thalesgroup.com>
To: "'Juergen Boldt'" <juergen@omg.org>, issues@omg.org, qvt-rtf@omg.org
Cc: "'peter.denno@nist.gov'" <peter.denno@nist.gov>
Subject: RE: issue 12367 -- QVT RTF issue
Date: Fri, 4 Apr 2008 07:48:32 +0100 
X-Mailer: Internet Mail Service (5.5.2656.59)


Hi Peter
 
This change is not necessary since 7.13.6 extends OclExpressionCS to include template.
 
<OclExpressionCS> ::= <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> | <LetExpCS> | <IfExpCS> | '(' <OclExpressionCS> ')' | <template> 

 
    Regards
 
        Ed Willink



--------------------------------------------------------------------------------
From: Juergen Boldt [mailto:juergen@omg.org] 
Sent: 03 April 2008 20:34
To: issues@omg.org; qvt-rtf@omg.org
Subject: issue 12367 -- QVT RTF issue


This is issue #12367    From: Peter Denno <peter.denno@nist.gov> 

Issue against QVT ptc/07-07-07 : relational grammar

Section 7.13.5 Relation BNF


The grammar rule for template is incorrect (It does not allow a 
template to have embedded within it another template. The example in 
Appendix A will not compile with such a grammar.)


It says:


<propertyTemplate> ::= <identifier> '=' <OclExpressionCS>


It should says:
<propertyTemplate> ::= <identifier> '=' ( <template> | 
<oclExpressionCS 


Juergen Boldt
Director, Member Services
Object Management Group
140 Kendrick St
Building A Suite 300
Needham, MA 02494
USA

tel: +1 781 444 0404 x 132
fax: +1 781 444 0320
email: juergen@omg.org
www.omg.org

*******************************************************************************

Please consider the environment before printing this email.

*******************************************************************************

This email and any files transmitted with it are intended solely for the use of

the individual or entity to whom they are addressed and may not be divulged to

any third party without the express permission of the originator. Any views

expressed in this message are those of the individual sender, except where the

sender specifically states them to be the views of Thales Research & Technology

(UK) Limited.

*******************************************************************************

 


X-IronPort-AV: E=Sophos;i="4.25,621,1199644200"; 
   d="scan'208,217";a="155629805"
To: Peter Denno <peter.denno@nist.gov>
Cc: "Willink, Ed" <Ed.Willink@thalesgroup.com>, qvt-rtf@omg.org
Subject: Re: issue 12367 -- QVT RTF issue
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
From: Sreedhar Reddy <sreedhar.reddy@tcs.com>
Date: Tue, 8 Apr 2008 11:06:03 +0530
X-MIMETrack: Serialize by Router on InMumM01/TCS(Release 6.5.5FP2HF415 | June 20, 2007) at
 04/08/2008 11:06:04,
        Serialize complete at 04/08/2008 11:06:04



Hi Peter, Ed, 

I agree with the suggestion that the rule is better written as: 
 <propertyTemplate> ::= <identifier> '=' ( <template> | <OclExpressionCS>) 
and remove <template> from the production of <OclExpressionCS>. 
<OclExpressionCS> is used in five other productions and this is the only place where <template> should be allowed. 

Thanks, 
Sreedhar 

Sreedhar S Reddy
Tata Consultancy Services
Mailto: sreedhar.reddy@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
____________________________________________ 


Peter Denno <peter.denno@nist.gov> 
04/08/2008 01:08 AM 
 To "Willink, Ed" <Ed.Willink@thalesgroup.com>  
cc qvt-rtf@omg.org  
Subject Re: issue 12367 -- QVT RTF issue 

  

 



On Monday 07 April 2008 14:04, Willink, Ed wrote:
> Hi Peter
>
> I'm not the author, but I'm prepared to defend the QVTr grammar
> anyway.
>
> The expression of a grammar is a compromise between semantic
> precision and a combinatorial complexity explosion.

Hi Ed,

I'm not sure I agree with that. For most computer languages, the 
grammar tells you the space of legal sentences. Some of those 
sentences might not be valid on the target machine, but they all are 
subject to further processing, resulting in instructions to the 
target machine.

You are saying this isn't true of QVT. If what you say is necessarily 
the case, then I guess we implementers would just pay the price by 
developing more complex tools. Writers of the specification would pay 
the price by laboring to describe what those additional constraints 
are (something the QVT writers ought to now do, if they aren't 
willing fix things). And readers of the spec would pay the price of 
having to read through all that extra stuff. 

I have a grammar that I think works for what is intended. My fledgling 
tool at least compiles and runs the RDBMS example in Annex A. Maybe 
you could tell me what is wrong with the production I'm suggesting, 
and we can work from there. 

I wrote the grammar of the ISO EXPRESS-X mapping language. So this 
work isn't new to me.

> A grammar generally tolerates a larger language (allows invalid
> constructs) and then relies on a set of semantic constraints to
> reduce the larger language.
>
> For instance, it is impractical with standard parsers to write a
> grammar that prohibits duplicate definitions, since the parser
> stack maintains only a branch rather than a tree of context.
> Detection of duplicates is therefore imposed as a constraint during
> a semantic analysis phase that follows lexical and syntactic
> analysis.
>
> With QVTr and QVTc (and perhaps QVTo) extending EssentialOCL it is
> a pragmatic convenience to just extend OclExpressionCS, since some
> usages of OclExpressionCS do need extending. The extension must be
> named OclExpressionCS to ensure that OCL is extended. (Many parser
> tools and EBNF allow this form of extension.)

If, like me, you already have an OCL tool that is used separate from 
this QVT work, you don't want to extend the OCL grammar. I think you 
are making some unnecessary assumptions about the tooling. 

Keep the specifications separate, and make the references to the OCL 
spec as clear as possible.

> This unfortunately extends more than is really necessary, so there
> is a case for providing more restrictive extensions where possible,
> but that could complicate the grammar.

We should be willing to make the grammar reflect what is intended. If 
that takes twice the number of productions the spec now has (I doubt 
that) would that make it too complicated? For tools? For human 
readers?

> Philosophically this is no different to an existing OCL grammar
> failing to adequately identify a BooleanExpression as a
> syntactically distinct concept from an arbitrary expression..

Quite a bit different IMO. What you describe concerns tracing types 
through expression syntax -- performed as analysis of the parse. 
That's hard. What we are talking about with respect to 
OCLExpressionCS is just a matter of generating error messages because 
we didn't bother to say that e.g. a template can't be the body of a 
when clause. (If that's what QVT intends. I don't see the answer in 
the spec.)

> The above justifies the syntactical exposition of the grammar.
> I will not attempt to justify the semantic exposition, which I
> feel is a major shortcoming in QVT 1.0 (already raised as an
> Issue.)

Probably more than '*an* issue' ;^)

> "OMG Issue No:10646: Missing explanations in BNF
> Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com
> ed@willink.me.uk)
> Summary:
> The OCL 2.0 spec has a 32 page section on concrete semantics.
> QVTr has 1.5 pages of BNF but no explanation.
> In particular:
> What are the semantics of 'import' which has no abstract
> counterpart? Where is the explanation of the role of [ '{' '}' ] in
> a ? Where is the instruction on how to treat the "_" identifier?
> Resolution: Deferred
> Comment:
> Specifying more formally the mapping between the concrete syntax
> and the metamodel -
> as it was achieved for the OCL language - could be interesting.
> However it is a very time
> expensive task. Also, may be difficult to maintain. We prefer defer
> such decision to a
> future RTF."
>
>                  Regards
>
>                                   Ed Willink
>
> *******************************************************************
>************ Please consider the environment before printing this
> email.
> *******************************************************************
>************ This email and any files transmitted with it are
> intended solely for the use of the individual or entity to whom
> they are addressed and may not be divulged to any third party
> without the express permission of the originator.  Any views
> expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Thales Research & Technology (UK) Limited.
> *******************************************************************
>************

-- 
Best regards,
 - Peter

ForwardSourceID:NT00034086     

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



From: "Willink, Ed" <Ed.Willink@thalesgroup.com>
To: "'Sreedhar Reddy'" <sreedhar.reddy@tcs.com>,
        Peter Denno <peter.denno@nist.gov>
Cc: qvt-rtf@omg.org
Subject: RE: issue 12367 -- QVT RTF issue
Date: Tue, 8 Apr 2008 11:25:48 +0100 
X-Mailer: Internet Mail Service (5.5.2656.59)


Hi Sreedhar, Peter
 
That's a superb simplification, but is it valid?
 
I thought the problem was that templates could also contribute to literal expressions
so that a template could be used in a variety of neutral OCL contexts such as let
variable initialisers or operation call arguments.
 
I've just changed my QVTr parser to exploit the simplification. All my tests pass, including
parsing RelToCore, so it looks like a very good improvement.
 
    Regards
 
        Ed Willink



--------------------------------------------------------------------------------
From: Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] 
Sent: 08 April 2008 06:36
To: Peter Denno
Cc: Willink, Ed; qvt-rtf@omg.org
Subject: Re: issue 12367 -- QVT RTF issue



Hi Peter, Ed, 

I agree with the suggestion that the rule is better written as: 
 <propertyTemplate> ::= <identifier> '=' ( <template> | <OclExpressionCS>) 
and remove <template> from the production of <OclExpressionCS>. 
<OclExpressionCS> is used in five other productions and this is the only place where <template> should be allowed. 

Thanks, 
Sreedhar 

Sreedhar S Reddy
Tata Consultancy Services
Mailto: sreedhar.reddy@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
____________________________________________ 


Peter Denno <peter.denno@nist.gov> 
04/08/2008 01:08 AM 
 To "Willink, Ed" <Ed.Willink@thalesgroup.com>  
cc qvt-rtf@omg.org  
Subject Re: issue 12367 -- QVT RTF issue 

  

 



On Monday 07 April 2008 14:04, Willink, Ed wrote:
> Hi Peter
>
> I'm not the author, but I'm prepared to defend the QVTr grammar
> anyway.
>
> The expression of a grammar is a compromise between semantic
> precision and a combinatorial complexity explosion.

Hi Ed,

I'm not sure I agree with that. For most computer languages, the 
grammar tells you the space of legal sentences. Some of those 
sentences might not be valid on the target machine, but they all are 
subject to further processing, resulting in instructions to the 
target machine.

You are saying this isn't true of QVT. If what you say is necessarily 
the case, then I guess we implementers would just pay the price by 
developing more complex tools. Writers of the specification would pay 
the price by laboring to describe what those additional constraints 
are (something the QVT writers ought to now do, if they aren't 
willing fix things). And readers of the spec would pay the price of 
having to read through all that extra stuff. 

I have a grammar that I think works for what is intended. My fledgling 
tool at least compiles and runs the RDBMS example in Annex A. Maybe 
you could tell me what is wrong with the production I'm suggesting, 
and we can work from there. 

I wrote the grammar of the ISO EXPRESS-X mapping language. So this 
work isn't new to me.

> A grammar generally tolerates a larger language (allows invalid
> constructs) and then relies on a set of semantic constraints to
> reduce the larger language.
>
> For instance, it is impractical with standard parsers to write a
> grammar that prohibits duplicate definitions, since the parser
> stack maintains only a branch rather than a tree of context.
> Detection of duplicates is therefore imposed as a constraint during
> a semantic analysis phase that follows lexical and syntactic
> analysis.
>
> With QVTr and QVTc (and perhaps QVTo) extending EssentialOCL it is
> a pragmatic convenience to just extend OclExpressionCS, since some
> usages of OclExpressionCS do need extending. The extension must be
> named OclExpressionCS to ensure that OCL is extended. (Many parser
> tools and EBNF allow this form of extension.)

If, like me, you already have an OCL tool that is used separate from 
this QVT work, you don't want to extend the OCL grammar. I think you 
are making some unnecessary assumptions about the tooling. 

Keep the specifications separate, and make the references to the OCL 
spec as clear as possible.

> This unfortunately extends more than is really necessary, so there
> is a case for providing more restrictive extensions where possible,
> but that could complicate the grammar.

We should be willing to make the grammar reflect what is intended. If 
that takes twice the number of productions the spec now has (I doubt 
that) would that make it too complicated? For tools? For human 
readers?

> Philosophically this is no different to an existing OCL grammar
> failing to adequately identify a BooleanExpression as a
> syntactically distinct concept from an arbitrary expression..

Quite a bit different IMO. What you describe concerns tracing types 
through expression syntax -- performed as analysis of the parse. 
That's hard. What we are talking about with respect to 
OCLExpressionCS is just a matter of generating error messages because 
we didn't bother to say that e.g. a template can't be the body of a 
when clause. (If that's what QVT intends. I don't see the answer in 
the spec.)

> The above justifies the syntactical exposition of the grammar.
> I will not attempt to justify the semantic exposition, which I
> feel is a major shortcoming in QVT 1.0 (already raised as an
> Issue.)

Probably more than '*an* issue' ;^)

> "OMG Issue No:10646: Missing explanations in BNF
> Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com
> ed@willink.me.uk)
> Summary:
> The OCL 2.0 spec has a 32 page section on concrete semantics.
> QVTr has 1.5 pages of BNF but no explanation.
> In particular:
> What are the semantics of 'import' which has no abstract
> counterpart? Where is the explanation of the role of [ '{' '}' ] in
> a ? Where is the instruction on how to treat the "_" identifier?
> Resolution: Deferred
> Comment:
> Specifying more formally the mapping between the concrete syntax
> and the metamodel -
> as it was achieved for the OCL language - could be interesting.
> However it is a very time
> expensive task. Also, may be difficult to maintain. We prefer defer
> such decision to a
> future RTF."
>
>                  Regards
>
>                                   Ed Willink
>
> *******************************************************************
>************ Please consider the environment before printing this
> email.
> *******************************************************************
>************ This email and any files transmitted with it are
> intended solely for the use of the individual or entity to whom
> they are addressed and may not be divulged to any third party
> without the express permission of the originator.  Any views
> expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Thales Research & Technology (UK) Limited.
> *******************************************************************
>************

-- 
Best regards,
 - Peter

ForwardSourceID:NT00034086     

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



X-IronPort-AV: E=Sophos;i="4.25,623,1199644200"; 
   d="scan'208";a="155750261"
X-DISCLAIMER: FALSE
To: "Willink, Ed" <Ed.Willink@thalesgroup.com>
Cc: Peter Denno <peter.denno@nist.gov>, qvt-rtf@omg.org
Subject: RE: issue 12367 -- QVT RTF issue
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
From: Sreedhar Reddy <sreedhar.reddy@tcs.com>
Date: Tue, 8 Apr 2008 17:31:03 +0530
X-MIMETrack: Serialize by Router on InMumM01/TCS(Release 6.5.5FP2HF415 | June 20, 2007) at
 04/08/2008 17:31:04,
        Serialize complete at 04/08/2008 17:31:04



Hi Ed, 

> I thought the problem was that templates could also contribute to 
> literal expressions 
> so that a template could be used in a variety of neutral OCL 
> contexts such as let 
> variable initialisers or operation call arguments. 
May be in a later version, but at present templates are meant to be used only to specify relation domain patterns. We will make this explicit. 

Thanks, 
Sreedhar 

Sreedhar S Reddy
Tata Consultancy Services
Mailto: sreedhar.reddy@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
____________________________________________ 

"Willink, Ed" <Ed.Willink@thalesgroup.com> wrote on 04/08/2008 03:55:48 PM:

> Hi Sreedhar, Peter 
>   
> That's a superb simplification, but is it valid? 
>   
> I thought the problem was that templates could also contribute to 
> literal expressions 
> so that a template could be used in a variety of neutral OCL 
> contexts such as let 
> variable initialisers or operation call arguments. 
>   
> I've just changed my QVTr parser to exploit the simplification. All 
> my tests pass, including 
> parsing RelToCore, so it looks like a very good improvement. 
>   
>     Regards 
>   
>         Ed Willink 
> 
> From: Sreedhar Reddy [mailto:sreedhar.reddy@tcs.com] 
> Sent: 08 April 2008 06:36
> To: Peter Denno
> Cc: Willink, Ed; qvt-rtf@omg.org
> Subject: Re: issue 12367 -- QVT RTF issue

> 
> Hi Peter, Ed, 
> 
> I agree with the suggestion that the rule is better written as: 
>  <propertyTemplate> ::= <identifier> '=' ( <template> | <OclExpressionCS>) 
> and remove <template> from the production of <OclExpressionCS>. 
> <OclExpressionCS> is used in five other productions and this is the 
> only place where <template> should be allowed. 
> 
> Thanks, 
> Sreedhar 
> 
> Sreedhar S Reddy
> Tata Consultancy Services
> Mailto: sreedhar.reddy@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________ 
> 

> 
> Peter Denno <peter.denno@nist.gov> 
> 04/08/2008 01:08 AM 
> 
> To 
> 
> "Willink, Ed" <Ed.Willink@thalesgroup.com> 
> 
> cc 
> 
> qvt-rtf@omg.org 
> 
> Subject 
> 
> Re: issue 12367 -- QVT RTF issue 
> 
> 
> 
> 
> On Monday 07 April 2008 14:04, Willink, Ed wrote:
> > Hi Peter
> >
> > I'm not the author, but I'm prepared to defend the QVTr grammar
> > anyway.
> >
> > The expression of a grammar is a compromise between semantic
> > precision and a combinatorial complexity explosion.
> 
> Hi Ed,
> 
> I'm not sure I agree with that. For most computer languages, the 
> grammar tells you the space of legal sentences. Some of those 
> sentences might not be valid on the target machine, but they all are 
> subject to further processing, resulting in instructions to the 
> target machine.
> 
> You are saying this isn't true of QVT. If what you say is necessarily 
> the case, then I guess we implementers would just pay the price by 
> developing more complex tools. Writers of the specification would pay 
> the price by laboring to describe what those additional constraints 
> are (something the QVT writers ought to now do, if they aren't 
> willing fix things). And readers of the spec would pay the price of 
> having to read through all that extra stuff. 
> 
> I have a grammar that I think works for what is intended. My fledgling 
> tool at least compiles and runs the RDBMS example in Annex A. Maybe 
> you could tell me what is wrong with the production I'm suggesting, 
> and we can work from there. 
> 
> I wrote the grammar of the ISO EXPRESS-X mapping language. So this 
> work isn't new to me.
> 
> > A grammar generally tolerates a larger language (allows invalid
> > constructs) and then relies on a set of semantic constraints to
> > reduce the larger language.
> >
> > For instance, it is impractical with standard parsers to write a
> > grammar that prohibits duplicate definitions, since the parser
> > stack maintains only a branch rather than a tree of context.
> > Detection of duplicates is therefore imposed as a constraint during
> > a semantic analysis phase that follows lexical and syntactic
> > analysis.
> >
> > With QVTr and QVTc (and perhaps QVTo) extending EssentialOCL it is
> > a pragmatic convenience to just extend OclExpressionCS, since some
> > usages of OclExpressionCS do need extending. The extension must be
> > named OclExpressionCS to ensure that OCL is extended. (Many parser
> > tools and EBNF allow this form of extension.)
> 
> If, like me, you already have an OCL tool that is used separate from 
> this QVT work, you don't want to extend the OCL grammar. I think you 
> are making some unnecessary assumptions about the tooling. 
> 
> Keep the specifications separate, and make the references to the OCL 
> spec as clear as possible.
> 
> > This unfortunately extends more than is really necessary, so there
> > is a case for providing more restrictive extensions where possible,
> > but that could complicate the grammar.
> 
> We should be willing to make the grammar reflect what is intended. If 
> that takes twice the number of productions the spec now has (I doubt 
> that) would that make it too complicated? For tools? For human 
> readers?
> 
> > Philosophically this is no different to an existing OCL grammar
> > failing to adequately identify a BooleanExpression as a
> > syntactically distinct concept from an arbitrary expression..
> 
> Quite a bit different IMO. What you describe concerns tracing types 
> through expression syntax -- performed as analysis of the parse. 
> That's hard. What we are talking about with respect to 
> OCLExpressionCS is just a matter of generating error messages because 
> we didn't bother to say that e.g. a template can't be the body of a 
> when clause. (If that's what QVT intends. I don't see the answer in 
> the spec.)
> 
> > The above justifies the syntactical exposition of the grammar.
> > I will not attempt to justify the semantic exposition, which I
> > feel is a major shortcoming in QVT 1.0 (already raised as an
> > Issue.)
> 
> Probably more than '*an* issue' ;^)
> 
> > "OMG Issue No:10646: Missing explanations in BNF
> > Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com
> > ed@willink.me.uk)
> > Summary:
> > The OCL 2.0 spec has a 32 page section on concrete semantics.
> > QVTr has 1.5 pages of BNF but no explanation.
> > In particular:
> > What are the semantics of 'import' which has no abstract
> > counterpart? Where is the explanation of the role of [ '{' '}' ] in
> > a ? Where is the instruction on how to treat the "_" identifier?
> > Resolution: Deferred
> > Comment:
> > Specifying more formally the mapping between the concrete syntax
> > and the metamodel -
> > as it was achieved for the OCL language - could be interesting.
> > However it is a very time
> > expensive task. Also, may be difficult to maintain. We prefer defer
> > such decision to a
> > future RTF."
> >
> >                  Regards
> >
> >                                   Ed Willink
> >
> > *******************************************************************
> >************ Please consider the environment before printing this
> > email.
> > *******************************************************************
> >************ This email and any files transmitted with it are
> > intended solely for the use of the individual or entity to whom
> > they are addressed and may not be divulged to any third party
> > without the express permission of the originator.  Any views
> > expressed in this message are those of the individual sender,
> > except where the sender specifically states them to be the views of
> > Thales Research & Technology (UK) Limited.
> > *******************************************************************
> >************
> 
> -- 
> Best regards,
>  - Peter
> 
> ForwardSourceID:NT00034086     
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you
> 
> 

> ForwardSourceID:NT000340DA    
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



  - Peter