v2 has the concept of "extensions", so what Andi and I decided (off-line)
is for the @Model annotation to be moved into an optional extension.
That'll make it easy for those who like the idea to include it in their
code, but not to be part of the formal programming model.
Thanks
Dan
On Tue, 24 Sep 2019 at 09:18, Andi Huber <ahu...@apache.org> wrote:
> Let me give a short summary of findings so far:
>
> 1. Currently the (core) framework's full introspection validation covers
> you (will emit a validation failure) in case you use one of the reserved
> prefixes for a public method (hide, validate, ...) and you got something
> wrong with it.
>
> 2. If your intent is to write a supporting-method, but you use the wrong
> prefix like ('verify' instead of correct 'validate') or declare it other
> than 'public', the framework will simply ignore your intent.
>
> 3. While not yet implemented, we could in principle allow reserved
> prefixes to be used with Actions/Properties/Collections, as long as
> these are explicitly annotated with @Action/@Property/@Collection.
>
> // should be a valid action name, even though 'disable' is reserved
> @Action public void disableUser(User user) {
> ..
> }
>
> 4. Lets assume we introduce a new annotation @Model (name still open for
> discussion), we then could use this as the semantic counterpart to
> @Programmatic and provide a means to solve (2).
>
> - @Programmatic ... to be ignored by the framework
> - @Model ... NOT to be ignored by the framework
>
> 5. In order to have features like (4) just as an option, without
> changing the framework's default behavior, we could provide these as
> extensions to the framework. So everybody is free to choose whether to
> use them.
>
> 6. The framework has a configuration option to either enforce use of
> annotation @Action or not. The recommended setting is to turn this
> enforcement on, because it allows to get rid of having to use
> @Programmatic on other (public) methods, one wants to be ignored by the
> framework. There is a consistency concern, in case we introduce a
> @Model annotation: Would we also want to provide an option to enforce
> it?
>
> I want to leave the discussion open some more days, and I also would
> like to encourage you to take the opportunity and tell us your personal
> pain-points with the framework in general. Maybe we can address these
> and take your feedback to improve the next release!
>
> Cheers, Andi
>
> On 2019/09/24 05:22:53, Brian K <harvestmoon...@gmail.com> wrote:
> > That is what I liked about the original version (Naked Objects). It was
> > very easy to start using. I don't recall any scaffolding needed in the
> > object classes. All method name conventions were interpreted the way
> > you'd expect. Maybe an improvement would be to implement defaults so a
> new
> > user doesn't have to copy from an example to get the annotations right.
> >
> > Annotations have the IDE advantage over name conventions, though. If we
> > implemented the support methods with an annotation `ActionModel` then I'd
> > expect that typing in `@ActionModel(` in Eclipse would give me all the
> > types of support options available to me.
> >
> > -Brian
> >
> > On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jdoornen...@incode.org>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have been following the conversation and I tend to agree with Dan.
> > > To limit the amount of annotations (and notions / conventions of the
> > > framework) in my opinion is more important then the convenience that
> this
> > > might give.
> > > I never experienced the need for this feature the last 4 years I have
> used
> > > the framework extensively for Estatio.
> > >
> > > Grtz from Johan
> > >
> > >
> > >
> > >
> > > Op ma 23 sep. 2019 om 14:14 schreef Andi Huber <ahu...@apache.org>:
> > >
> > > > It seems @Model is more popular than @Support, only inconvenience is
> a
> > > > naming clash with [1].
> > > >
> > > > I'll bring another aspect to the table, that is prefixes like 'hide',
> > > > 'disable', ... could/should be allowed for Actions. We can discuss
> how
> > > > following domain-object examples should get interpreted by the
> framework.
> > > > (Comments according to what I think makes most sense) ...
> > > >
> > > > public class Object1 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // proper supporting-method naming, will get picked up by the
> > > > framework and added
> > > > // to the metamodel (no annotation required)
> > > > public boolean hideMyProperty() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > public class Object2 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // allowed, nothing wrong with that, might either be picked up
> as an
> > > > action
> > > > // or gets ignored, depending on the framework's configuration,
> > > > // whether the @Action annotation is mandatory or not;
> > > > // however, this is no supporting-method!
> > > > public boolean hideWhatever() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > public class Object3 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // will fail, because this method is clearly orphaned
> > > > @Model
> > > > public boolean hideWhatever() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > [1]
> > > >
> https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html
> > > >
> > > > On 2019/09/23 05:54:52, Andi Huber <ahu...@apache.org> wrote:
> > > > > Yes, there are lots of cases already covered, but not those, when
> you
> > > > get the intended supporting-method's prefix wrong.
> > > > >
> > > > > Typically, when writing new domain-code I'd start with some
> properties
> > > > and actions and then eventually add supporting-methods. At the time
> of
> > > > writing these, I have a clear intent, that I want these to be added
> to
> > > the
> > > > model no matter what, and I want to be warned when I get something
> wrong.
> > > > This annotation (@Support or @Model) should allow me to express this
> > > > intent. (However you don't have to, its optional.)
> > > > >
> > > > > @Brian: You brought the 'addChild(Child ...)' example, where your
> > > intent
> > > > is to have this as an Action? If so, the framework should be able to
> > > > undersand this intent, when the addChild method is annotated with
> > > @Action.
> > > > Otherwise we have a bug.
> > > > >
> > > > > Cheers, Andi
> > > > >
> > > > > On 2019/09/23 03:58:28, Dan Haywood <d...@haywood-associates.co.uk>
> > > > wrote:
> > > > > > I'm afraid that I don't understand the idea.
> > > > > >
> > > > > > There are already config properties that enable fail-fast
> validation
> > > > that
> > > > > > detect orphaned supporting methods (and other checks besides).
> Why
> > > do
> > > > we
> > > > > > need an annotation to ask for this to be done? It just adds
> clutter
> > > in
> > > > my
> > > > > > view?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Sun, 22 Sep 2019, 21:07 Brian K, <harvestmoon...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > I like the @Support annotation, not @Action, because validate
> is
> > > not
> > > > an
> > > > > > > action.
> > > > > > >
> > > > > > > Most of my frustration on this front has been inadvertently
> > > creating
> > > > a
> > > > > > > supporting function. like:
> > > > > > > addChild(Child child){...}
> > > > > > >
> > > > > > > Can these patterns be optional when the annotations are active?
> > > > Maybe a
> > > > > > > isis.properties switch?
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Brian
> > > > > > >
> > > > > > > On Sun, Sep 22, 2019 at 3:19 AM Andi Huber <ahu...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > > If we would not have the freedom of introducing a new
> annotation,
> > > > > > > > @Action(type=Supporting)
> > > > > > > > would be a good choice as well, but we also have supporting
> > > > methods for
> > > > > > > > Properties and Collections!
> > > > > > > >
> > > > > > > > But since we have @Action, @Property and @Collection all with
> > > good
> > > > > > > > justification to stand and represent their own kind, we
> might as
> > > > well
> > > > > > > > introduce a new one here!?
> > > > > > > >
> > > > > > > > I was also thinking about @Model, which is a bit more
> generic and
> > > > may
> > > > > > > > allow for more flexible use later on.
> > > > > > > >
> > > > > > > > On 2019/09/22 08:47:20, "Rade, Joerg / Kuehne + Nagel / HAM
> > > GI-DP"
> > > > > > > > <joerg.r...@kuehne-nagel.com> wrote:
> > > > > > > > > Hi Andi,
> > > > > > > > >
> > > > > > > > > I like the idea of using an annotation, because it makes
> the
> > > > > > > programming
> > > > > > > > model more consistent.
> > > > > > > > >
> > > > > > > > > Maybe @Action(type=Supporting) ?
> > > > > > > > >
> > > > > > > > > -j
> > > > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > > > Von: Andi Huber [mailto:ahu...@apache.org]
> > > > > > > > > Gesendet: Sonntag, 22. September 2019 10:01
> > > > > > > > > An: users@isis.apache.org
> > > > > > > > > Betreff: Extending the Programming Model with @Support?
> > > > > > > > >
> > > > > > > > > Hi folks,
> > > > > > > > >
> > > > > > > > > we are still making progress towards Apache Isis Version 2.
> > > > While most
> > > > > > > > of the work goes into technical topics that stay under the
> hood,
> > > > like
> > > > > > > > decoupling from JDO, there are also some changes to the
> > > programming
> > > > > > > model,
> > > > > > > > that will affect you and require migration of your
> domain-code.
> > > > > > > > >
> > > > > > > > > We have no concrete release plan yet, we thought maybe
> October
> > > > for a
> > > > > > > > preview, we'll see.
> > > > > > > > >
> > > > > > > > > Anyway I do have a questions regarding the programming
> model:
> > > > > > > > >
> > > > > > > > > Have you ever run into the issue of misspelling a
> > > > supporting-method
> > > > > > > > within your domain-code
> > > > > > > > > eg. verifyMyAction(...) instead of correct
> > > validateMyAction(...)
> > > > then
> > > > > > > > spending some time to troubleshot this? What an
> inconvenience!
> > > > > > > > >
> > > > > > > > > My proposed solution to this is to introduce a new
> annotation
> > > to
> > > > make a
> > > > > > > > contract with the domain-model (meta-model) :
> > > > > > > > >
> > > > > > > > > @Action
> > > > > > > > > public void myAction() {
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > @Support // <-- to enforce a contract with the domain-model
> > > > > > > > > public boolean hideMyAction() {
> > > > > > > > > ...
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > * The 'hideMyAction' method is termed 'supporting-method'.
> We
> > > > have lots
> > > > > > > > of variants of these. (validateX, disableX, ...)
> > > > > > > > > * This contract allows for a check whether the intended
> > > > > > > > supporting-method gets picked up by the framework and is not
> > > > ignored.
> > > > > > > That
> > > > > > > > way we can emit a validation failure, if a support-method is
> > > > misspelled
> > > > > > > or
> > > > > > > > does have any other deficiencies.
> > > > > > > > > * The @Support annotation is optional, does not require
> you to
> > > > migrate
> > > > > > > > your domain-code.
> > > > > > > > >
> > > > > > > > > Do you like the concept? Should we use a better name for
> the
> > > > > > > annotation?
> > > > > > > > Can we reuse/repurpose any existing annotation?
> > > > > > > > >
> > > > > > > > > Any thoughts?
> > > > > > > > >
> > > > > > > > > Cheers, Andi
> > > > > > > > >
> > > > > > > > > Kühne + Nagel (AG & Co.) KG
> > > > > > > > > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928,
> USt-IdNr.:
> > > > DE
> > > > > > > > 812773878.
> > > > > > > > > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Holger Ketz
> > > (Vors.
> > > > ),
> > > > > > > > Martin Brinkmann, Lars-Olof Grün, Matthias Knicky, Nicholas
> > > Minde,
> > > > > > > Johannes
> > > > > > > > Trimborn, Lars Wedel, Matthias Weiner.
> > > > > > > > > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G.,
> > > > Rechtsform:
> > > > > > > > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B
> 18745,
> > > > > > > > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> > > > > > > > > Geschäftsleitung Region Europa: Dr. Hansjörg Rodi (Vors.),
> Mart
> > > > Ambur,
> > > > > > > > Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard
> Huhn,
> > > > > > > Jan-Hendrik
> > > > > > > > Köstergarten, Heiko Schuhmacher.
> > > > > > > > >
> > > > > > > > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen
> > > > Deutschen
> > > > > > > > Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017
> > > > weichen in
> > > > > > > > Ziffer 23 hinsichtlich des Haftungshöchstbetrages für
> > > Güterschäden
> > > > (§ 431
> > > > > > > > HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
> > > > Transporten
> > > > > > > > unter Einschluss einer Seebeförderung und bei unbekanntem
> > > > Schadenort auf
> > > > > > > 2
> > > > > > > > SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg
> zusätzlich
> > > > auf
> > > > > > > 1,25
> > > > > > > > Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je
> > > > > > > Schadenereignis,
> > > > > > > > mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf
> unserer
> > > > Webseite
> > > > > > > > als Download erhältlich. Auf Anfrage senden wir Ihnen diese
> auch
> > > > gerne
> > > > > > > zu.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > On Mon, Sep 23, 2019, 5:18 AM Johan Doornenbal <jdoornen...@incode.org>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have been following the conversation and I tend to agree with Dan.
> > > To limit the amount of annotations (and notions / conventions of the
> > > framework) in my opinion is more important then the convenience that
> this
> > > might give.
> > > I never experienced the need for this feature the last 4 years I have
> used
> > > the framework extensively for Estatio.
> > >
> > > Grtz from Johan
> > >
> > >
> > >
> > >
> > > Op ma 23 sep. 2019 om 14:14 schreef Andi Huber <ahu...@apache.org>:
> > >
> > > > It seems @Model is more popular than @Support, only inconvenience is
> a
> > > > naming clash with [1].
> > > >
> > > > I'll bring another aspect to the table, that is prefixes like 'hide',
> > > > 'disable', ... could/should be allowed for Actions. We can discuss
> how
> > > > following domain-object examples should get interpreted by the
> framework.
> > > > (Comments according to what I think makes most sense) ...
> > > >
> > > > public class Object1 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // proper supporting-method naming, will get picked up by the
> > > > framework and added
> > > > // to the metamodel (no annotation required)
> > > > public boolean hideMyProperty() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > public class Object2 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // allowed, nothing wrong with that, might either be picked up
> as an
> > > > action
> > > > // or gets ignored, depending on the framework's configuration,
> > > > // whether the @Action annotation is mandatory or not;
> > > > // however, this is no supporting-method!
> > > > public boolean hideWhatever() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > public class Object3 {
> > > >
> > > > @Property @Getter @Setter
> > > > private String myProperty;
> > > >
> > > > // will fail, because this method is clearly orphaned
> > > > @Model
> > > > public boolean hideWhatever() {
> > > > return false;
> > > > }
> > > >
> > > > }
> > > >
> > > > [1]
> > > >
> https://docs.oracle.com/javaee/7/api/javax/enterprise/inject/Model.html
> > > >
> > > > On 2019/09/23 05:54:52, Andi Huber <ahu...@apache.org> wrote:
> > > > > Yes, there are lots of cases already covered, but not those, when
> you
> > > > get the intended supporting-method's prefix wrong.
> > > > >
> > > > > Typically, when writing new domain-code I'd start with some
> properties
> > > > and actions and then eventually add supporting-methods. At the time
> of
> > > > writing these, I have a clear intent, that I want these to be added
> to
> > > the
> > > > model no matter what, and I want to be warned when I get something
> wrong.
> > > > This annotation (@Support or @Model) should allow me to express this
> > > > intent. (However you don't have to, its optional.)
> > > > >
> > > > > @Brian: You brought the 'addChild(Child ...)' example, where your
> > > intent
> > > > is to have this as an Action? If so, the framework should be able to
> > > > undersand this intent, when the addChild method is annotated with
> > > @Action.
> > > > Otherwise we have a bug.
> > > > >
> > > > > Cheers, Andi
> > > > >
> > > > > On 2019/09/23 03:58:28, Dan Haywood <d...@haywood-associates.co.uk>
> > > > wrote:
> > > > > > I'm afraid that I don't understand the idea.
> > > > > >
> > > > > > There are already config properties that enable fail-fast
> validation
> > > > that
> > > > > > detect orphaned supporting methods (and other checks besides).
> Why
> > > do
> > > > we
> > > > > > need an annotation to ask for this to be done? It just adds
> clutter
> > > in
> > > > my
> > > > > > view?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Sun, 22 Sep 2019, 21:07 Brian K, <harvestmoon...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > I like the @Support annotation, not @Action, because validate
> is
> > > not
> > > > an
> > > > > > > action.
> > > > > > >
> > > > > > > Most of my frustration on this front has been inadvertently
> > > creating
> > > > a
> > > > > > > supporting function. like:
> > > > > > > addChild(Child child){...}
> > > > > > >
> > > > > > > Can these patterns be optional when the annotations are active?
> > > > Maybe a
> > > > > > > isis.properties switch?
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Brian
> > > > > > >
> > > > > > > On Sun, Sep 22, 2019 at 3:19 AM Andi Huber <ahu...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > > If we would not have the freedom of introducing a new
> annotation,
> > > > > > > > @Action(type=Supporting)
> > > > > > > > would be a good choice as well, but we also have supporting
> > > > methods for
> > > > > > > > Properties and Collections!
> > > > > > > >
> > > > > > > > But since we have @Action, @Property and @Collection all with
> > > good
> > > > > > > > justification to stand and represent their own kind, we
> might as
> > > > well
> > > > > > > > introduce a new one here!?
> > > > > > > >
> > > > > > > > I was also thinking about @Model, which is a bit more
> generic and
> > > > may
> > > > > > > > allow for more flexible use later on.
> > > > > > > >
> > > > > > > > On 2019/09/22 08:47:20, "Rade, Joerg / Kuehne + Nagel / HAM
> > > GI-DP"
> > > > > > > > <joerg.r...@kuehne-nagel.com> wrote:
> > > > > > > > > Hi Andi,
> > > > > > > > >
> > > > > > > > > I like the idea of using an annotation, because it makes
> the
> > > > > > > programming
> > > > > > > > model more consistent.
> > > > > > > > >
> > > > > > > > > Maybe @Action(type=Supporting) ?
> > > > > > > > >
> > > > > > > > > -j
> > > > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > > > Von: Andi Huber [mailto:ahu...@apache.org]
> > > > > > > > > Gesendet: Sonntag, 22. September 2019 10:01
> > > > > > > > > An: users@isis.apache.org
> > > > > > > > > Betreff: Extending the Programming Model with @Support?
> > > > > > > > >
> > > > > > > > > Hi folks,
> > > > > > > > >
> > > > > > > > > we are still making progress towards Apache Isis Version 2.
> > > > While most
> > > > > > > > of the work goes into technical topics that stay under the
> hood,
> > > > like
> > > > > > > > decoupling from JDO, there are also some changes to the
> > > programming
> > > > > > > model,
> > > > > > > > that will affect you and require migration of your
> domain-code.
> > > > > > > > >
> > > > > > > > > We have no concrete release plan yet, we thought maybe
> October
> > > > for a
> > > > > > > > preview, we'll see.
> > > > > > > > >
> > > > > > > > > Anyway I do have a questions regarding the programming
> model:
> > > > > > > > >
> > > > > > > > > Have you ever run into the issue of misspelling a
> > > > supporting-method
> > > > > > > > within your domain-code
> > > > > > > > > eg. verifyMyAction(...) instead of correct
> > > validateMyAction(...)
> > > > then
> > > > > > > > spending some time to troubleshot this? What an
> inconvenience!
> > > > > > > > >
> > > > > > > > > My proposed solution to this is to introduce a new
> annotation
> > > to
> > > > make a
> > > > > > > > contract with the domain-model (meta-model) :
> > > > > > > > >
> > > > > > > > > @Action
> > > > > > > > > public void myAction() {
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > @Support // <-- to enforce a contract with the domain-model
> > > > > > > > > public boolean hideMyAction() {
> > > > > > > > > ...
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > * The 'hideMyAction' method is termed 'supporting-method'.
> We
> > > > have lots
> > > > > > > > of variants of these. (validateX, disableX, ...)
> > > > > > > > > * This contract allows for a check whether the intended
> > > > > > > > supporting-method gets picked up by the framework and is not
> > > > ignored.
> > > > > > > That
> > > > > > > > way we can emit a validation failure, if a support-method is
> > > > misspelled
> > > > > > > or
> > > > > > > > does have any other deficiencies.
> > > > > > > > > * The @Support annotation is optional, does not require
> you to
> > > > migrate
> > > > > > > > your domain-code.
> > > > > > > > >
> > > > > > > > > Do you like the concept? Should we use a better name for
> the
> > > > > > > annotation?
> > > > > > > > Can we reuse/repurpose any existing annotation?
> > > > > > > > >
> > > > > > > > > Any thoughts?
> > > > > > > > >
> > > > > > > > > Cheers, Andi
> > > > > > > > >
> > > > > > > > > Kühne + Nagel (AG & Co.) KG
> > > > > > > > > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928,
> USt-IdNr.:
> > > > DE
> > > > > > > > 812773878.
> > > > > > > > > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Holger Ketz
> > > (Vors.
> > > > ),
> > > > > > > > Martin Brinkmann, Lars-Olof Grün, Matthias Knicky, Nicholas
> > > Minde,
> > > > > > > Johannes
> > > > > > > > Trimborn, Lars Wedel, Matthias Weiner.
> > > > > > > > > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G.,
> > > > Rechtsform:
> > > > > > > > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B
> 18745,
> > > > > > > > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> > > > > > > > > Geschäftsleitung Region Europa: Dr. Hansjörg Rodi (Vors.),
> Mart
> > > > Ambur,
> > > > > > > > Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard
> Huhn,
> > > > > > > Jan-Hendrik
> > > > > > > > Köstergarten, Heiko Schuhmacher.
> > > > > > > > >
> > > > > > > > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen
> > > > Deutschen
> > > > > > > > Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017
> > > > weichen in
> > > > > > > > Ziffer 23 hinsichtlich des Haftungshöchstbetrages für
> > > Güterschäden
> > > > (§ 431
> > > > > > > > HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
> > > > Transporten
> > > > > > > > unter Einschluss einer Seebeförderung und bei unbekanntem
> > > > Schadenort auf
> > > > > > > 2
> > > > > > > > SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg
> zusätzlich
> > > > auf
> > > > > > > 1,25
> > > > > > > > Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je
> > > > > > > Schadenereignis,
> > > > > > > > mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf
> unserer
> > > > Webseite
> > > > > > > > als Download erhältlich. Auf Anfrage senden wir Ihnen diese
> auch
> > > > gerne
> > > > > > > zu.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
