I agree with Claudio.

If I say it in my words, SQL distinguishes
- updatable views (e.g. CREATE VIEW UV AS SELECT f FROM t)
- read-only views (e.g. CREATE VIEW RV AS SELECT f FROM t,rdb$database)

SQL standard does not allow (does not require support for) triggers on views,
but in FB it is very useful feature because it can make read-only views updatable.

The problem is that users sometimes need simple (updatable) views that
- fire its triggers AND perform default action
(current behaviour), e.g. replication engine can thus by-pass triggers.
- fire its triggers, but do NOT perform default action,
e.g. to change semantics of DELETE command to only update the status field.

So we need mechanism and syntax for changing naturally updatable
views to read-only views (that can't do default action).
(Of course I am talking about view alone;
view + trigger (of appripriate type) is always updatable.)
Hence my suggesion is to use syntax with READ ONLY.
e.g. CREATE READ ONLY VIEW ... or similar.
In other words, view is read-only
- implicitly (if it does not qualify as updatable by SQL rules)
- explicitly (by READ ONLY or similar clause)

For me such syntax is more intuitive than
[for trigger update]
or
[for trigger action]

(Mind it is only suggestion, I do not intend to fight for it.)

====
Other idea is to allow/disallow default action selectively,
e.g. allow it for insert, update, disallow for delete.
Hmmm, it's nonsense, I know ... :-)

Ivan
http://www.volny.cz/iprenosil/interbase