Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2
Hi Sergey

Thank you for your comments. Unfortunately the timing is very awkward. The preview is the time for comments and discussion.

Ballot 1 has already completed and is being reballotted and closes in 7 hours. I don't think I can change or even withdraw these resolutions. The relevant issues are WIBNIFs so the questioned resolutions are not damaging. Unfortunately we then hit an OMG restriction on reballotting to change a decision. These issues will have to be re-raised in a way that makes them look like new problems worthy of consideration. I totally agree with deepClone, but was relectant to go incompatible. getURI needs more thought.

Ballot 2 has only 8 hours to go. I can't change resolutions, but I can withdraw them. I'm inclined to withdraw 14620 since it actually breaks something. The others are inelegant.

Ballot 3 has only just started, so there is plenty of time for voters to consider changes. In 12526, 15977 of course you are correct about exceptionVariable, but I don't agree with an empty exception clause. Please start a new thread urgently if you want to discuss this.

    Regards

        Ed

On 05/02/2014 16:35, Sergey Boyko wrote:
Hi Ed,

Some comments are below:


QVT 1.2 Revision Task Force
Ballot 1 “Preview 1”


Issue 13988: Capitalization of leading characters in multiword operation names.

I consider this proposal is very sensible. It should not be closed. It's always good to use CamelCase to increase readability. All existing namings like 'deepclone' should be marked as 'deprecated'.


Issue 15215: QVT1.1: Add an operation Model::getURI().

   Useful proposal. Should not be closed. To me suitable name for such function is 'Model::getResourceURI()'. I do not share described doubts. In most mentioned questionable cases an empty string should be returned as the result of the call.
 


QVT 1.2 Revision Task Force
Ballot 2 “Preview 1”


Issue 13265: Page 65, Notation Section 8.2.1.3 Module.

Proposed resolution is incorrect. The context specification here is very confusing, it should be removed. Configuration property is (unlike the contextual property) defined in context of transformation.
Thus Revised Text should be:
  to
  Properties that are configuration properties are declared using the configuration qualifier keyword.
  configuration property MAX_SIZE : String;


Issue 14620: QVT 1.1 Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution).

Proposed resolution is incorrect. ListLiteralExp correctly extends CollectionLiteralExp type thus allowing to reuse existing CollectionLiteralPart.


Issue 15978: clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1.

To me StringException is redundant and useless. Consider Java exception hierarchy, even Throwable declares Throwable(String).
Really, base class in hierarchy does not have to be abstract.
So (as it was proposed) String message attribute for Exception is right decision. And dedicated StringException is not needed and should be removed.


Issue 19146: Specify List::reject and other iterations.

Operation 'deepclone()' should be spelled as 'deepClone()'.
Operation 'List::asList()' duplicates 'List::clone()'. Duplication always has 'bad smell' and should be avoided to not confusing users. Since both operation are really the same then the first should be removed.


Issue 19178: What happens when an exception is thrown by an exception handler.

Absolutely unrelated topic. QVTo takes Java approach so nested exception is allowed and processed normally. 
Link to C++ is misinterpreted. Nested exceptions certainly are allowed and widely used in C++.

It seems that proposed resolution implied SEH (Structured Exception Handling, SEH) exceptions instead of typed C++.  SEH comes from OS and was designed for C. MSDN says "Structured exception handling works with C and C++ source files. However, it is not specifically designed for C++." So they are definitely not an example for QVTo.

The issue should be closed (not resolved).


QVT 1.2 Revision Task Force
Ballot 3 “Preview 1”


Issue 12526: Errors and anomalies in QVT 1.0 07-07-08 ZIP imperativeocl.ecore.

Property 'CatchExp.exceptionVariableName' is incorrect. There should be 'CatchExp.exceptionVariable : Variable {composes} [0..1]' in order to preserve type also.

Changing multiplicity of 'CatchExp.exception' from '*' to '+' is incorrect. Multiplicity for 'CatchExp.exception' should be '*' (so that empty 'except' statement is handled).


Issue 15977: abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.

First, revised text for 'CatchExp.exceptionVariable' should be:
  In 8.2.2.14 CatchExp and the QVT 1.1 models add
    exceptionVariable : Variable [0..1]

Second, revised text incorrectly alters description for 'CatchExp.exception'. It should be:
  In 8.2.2.14 CatchExp and the QVT 1.1 models change
    exception: Type [*] {ordered}

Third, EBNF for '<except>' is incorrect. It should be:
   In 8.4.7 change
     to
  <except> ::= 'except' '(' <except_type_list_opt> ')' <expression_block>
  <except> ::= 'except' '(' IDENTIFIER ':' <type_list> ')' <expression_block>
  <except_type_list_opt> -> <type_list> 
  <except_type_list_opt> ::= %empty


Regards,
  Sergey.



On Mon, Feb 3, 2014 at 11:01 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

Note that voting for Ballot 1 reballot is still open. Please vote.
Note that voting for Ballot 2 is still open. Please vote.

The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1).

Preview 30-Jan to 5-Feb
Voting 5-Feb to 19-Feb

Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine).

I have managed to provide simple resolutions to two previously deferred issues.

Issue 12518 is substantially updated to include the redrawn Papyrus diagrams.

The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models

    Regards

        Ed Willink



_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev




_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7062 - Release Date: 02/04/14


Back to the top