Review Comment:
I already reviewed this paper before. There are some improvements after the resubmission, but the presentation still leaves much to be desired. First of all the authors did not fully address the issues raised by the reviewers. Secondly, the paper is too unclear at many places.
More comments follow below, but at some point I stopped since I gave up.
The authors made considerable improvements on the paper,
specially on the writing. Unfortunately, the cover letter that
supposedly explains/describes the changes is not detailed
enough. It is customary (and desirable) that the authors
address the issues raised by the reviewers one by one. Instead,
they made only general remarks about the changes.
Among other problems with this approach (to cover letter
writing), we find that the authors overlook changes required by
the reviewers. This is the case with my review, which makes me
unhappy, to say the least. I have to incur in extra time and
effort to indicate desirable and the same changes once more.
My main problem is (still) the introduction. It does not
properly convey the results obtained in this paper. Nor the
idea behind the approach. A main problem addressed in this
paper is that the external data sources may make a transaction
fail. This requires rollback or execution of compensation
actions. Transaction logic as known so far does not include
these elements. So, I would expect something to be said already
in the introduction, and also about how these problems are
going to be solved in the rest of the paper. I would imagine
that the rollback need a fixed, special semantics, but not
necessarily compensation. So, how are compensating transactions
or actions captured (formalized) and forced to be executed?
It is also desirable and common that at least a minimum amount
of related work is mentioned and described in the introduction.
This does not preclude having a later section on related work
where technical comments and comparisons are made. In
particular (and as already said in my previous review), Kifer
has applied TL to web service composition. Web services by
their very nature are beyond the control of the issuer of a
transaction (in transaction logic). So, he must have confronted
a similar problem. How do he handle it? What are the
shortcomings of his approach? How are them addressed here? Etc.
Etc.
The authors ignored my pointing out the work by Eiter et al. on
answer of giving a semantics to them is not far from the
problem treated here.
The authors keep talking in the introduction about consistency
(in the sense of ACID). What does it mean in this context?
Consistency wrt what?
I think the introduction does not need so many examples. It
would be better to include something around my comments above.
Specific comments: (some of them made in the previous review)
- page 2, col. 1, top: explain the idea of "independence of the
state or update semantics ..."
A few lines below: "w.r.t. the semantics ..." semantics of
what?
- Page 3, col. 1, bottom: at that stage talking about "London
and Paris not being *entailed* ..." does not make any sense
A few lines next, top of col. 2: you mention the rollback. A
good place to elaborate on rollback.
- Page 4, col. 2, top: The consistency issue ...
Further down in this column: the description of results is very
poor ... and the description of the problems improved wrt the
previous version, but still leaves much to be desired.
- Page 4, col. 1, beginning last paragraph: why is that a
*result*? Actually what does the whole sentence mean?
- Page 4, col. 2, "Relational oracles": what if the external
relational database has integrity constraints? It may not be
just a matter of deleting one tuple, there may be internal
ramifications, which could have an effect on a later
interaction with the same transaction. Something should be said
(and done) about this issue and others. How does really the
oracle behaves and what does the external transaction know
about it? Going beyond: what kind of frame axioms or
commonsense knowledge is available/used by the external
transaction (in TL)?
- Page 6, col 1: Poorly done ...
In line 15, what does it mean? What's that? What kind of
formula? What are the language's signature? A same kind of
formula cannot be used both with the data and the transition
oracle. For the latter, predicates with "del", "ins" are
required, but are not understood by the former. Def. 1 below
does not make the difference.
By the way, what is the notion of satisfaction in relation to
the oracles? In particular, with the transition oracle and
pairs of structures? Too much is being left implicit and/or
unclear.
- Page 7, col. 1: The authors freely talk about "transactions"
(they are entailed, they succeed, etc.). What exactly is a
transaction? There is no definition.
- Defs. 4 and 6: I do not understand how they combine. The
former requires satisfaction *for every path* for the M part
(for being a model of the program). So, what is the role of
in the latter?
- Page 8, Col. 2, and next column: It is never made clear that
the contents here is colloquial, and that precise definitions
will come later. So, at this point all this is highly confusing
and misleading.
It should also be said where the rollback and compensations are
captured in the logic. At this stage I have no clue about how
the authors plan to handle that, and this is the main point of
this paper.
- I do not understand why in sec. 3 (and 3.1_ the authors start
talking about actions (for the fist time). If there are actions
in this language, they should have naturally appeared before
even confronting the external domains.
- Sec. 3.1 is not for human consumption ...
I give up!
|