You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by James Hang <jh...@bea.com> on 2006/11/15 02:22:49 UTC
Versioning question
Hi,
I have a question about versioning, in particular how you would create child
nodes of a versioned node that are not versioned with the parent and can be
modified entirely independent of its parent.
For example, let's say I have a type T1. Nodes of T1 can have child nodes of
type T2. Nodes of type T2 can have child nodes of type T3.
So, my node tree will be like this:
T1
|_
T2 ...
|_
T3 ...
Now, let's say that I want to make it so that when I create a new version of
T1, I don't want T2 or its descendents to be part of the state that version.
One way I can do this by making the onParentVersion attribute of T2 and T3
to be IGNORE. However, in order to modify the T3 nodes, I will still have
to checkout/checkin a new version of its T1 ancestor. Is there a way to
avoid this?
I understand that adding/deleting T2 nodes will have to require checking out
T1, since the state of T1 will have to be modified. But it seems like you
should be able to modify T2 properties and add/delete T3 nodes without
having to do a checkout. Essentially, is there a way to make T2/T3 nodes
act like non-versionable standalone nodes, even though they are part of the
node hierarchy of a versionable node?
--
View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Versioning question
Posted by James Hang <jh...@bea.com>.
Thanks for opening up this discussion. I would definitely like this to
feature to be implemented in Jackrabbit. It would seem like the logical way
for Jackrabbit to behave.
Do you know if the JSR170 (or 283) spec mentions anything regarding this? I
couldn't find anything myself.
Thanks,
James
Tobias Bocanegra wrote:
>
> well, i'm not sure if we discussed this in the jackrabbit list or in
> the jsr283 list. but since OPV=ignore properties/nodes are excluded in
> the frozen state of a version anyways, they should be modifiable even
> if the parent node is checked-in.
>
> i opened a jira issue for further discussion.
> http://issues.apache.org/jira/browse/JCR-639
>
> regards, toby
>
> On 11/16/06, James Hang <jh...@bea.com> wrote:
>>
>> I assume you would still need to checkout and create a new version of T1
>> everytime you want to modify T2,T3 nodes. I'd like to be able to modify
>> T2,T3 nodes completely indepedent of T1...
>>
>>
>>
>> Tobias Bocanegra wrote:
>> >
>> > so you want T2,T3:
>> > - not versionable
>> > - ignored by T1
>> > - but not overridden on restore of T1
>> >
>> > but this should be possible with OPV=Ignore and 'removeExisting=false'
>> > on restore.
>> >
>> > regards, toby
>> >
>> > On 11/15/06, James Hang <jh...@bea.com> wrote:
>> >>
>> >> What if I don't want T2 and T3 to have version history at all? So
>> that I
>> >> can
>> >> modify them as independent non-versionable nodes (no checkout/checkin
>> >> required). Is this possible to do? I guess maybe what might make
>> more
>> >> sense in my case is if I just put T2 and T3 nodes outside of the T1
>> >> hierarchy and just have a references to them....
>> >>
>> >>
>> >>
>> >> Tobias Bocanegra wrote:
>> >> >
>> >> > yes, there is: you need to make them: OnParentVersion = VERSION.
>> >> > this means, that their existence is recorded in version of T1 but
>> not
>> >> > there contents (if they are mix:versionable, also) i know the
>> >> > versioning section in jsr170 is a bit confusing, but after having
>> read
>> >> > it 20 times, i start to understand it :-)
>> >> >
>> >> > regards, toby
>> >> >
>> >> >
>> >> > On 11/15/06, James Hang <jh...@bea.com> wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I have a question about versioning, in particular how you would
>> create
>> >> >> child
>> >> >> nodes of a versioned node that are not versioned with the parent
>> and
>> >> can
>> >> >> be
>> >> >> modified entirely independent of its parent.
>> >> >>
>> >> >> For example, let's say I have a type T1. Nodes of T1 can have child
>> >> nodes
>> >> >> of
>> >> >> type T2. Nodes of type T2 can have child nodes of type T3.
>> >> >>
>> >> >> So, my node tree will be like this:
>> >> >>
>> >> >> T1
>> >> >> |_
>> >> >> T2 ...
>> >> >> |_
>> >> >> T3 ...
>> >> >>
>> >> >> Now, let's say that I want to make it so that when I create a new
>> >> version
>> >> >> of
>> >> >> T1, I don't want T2 or its descendents to be part of the state that
>> >> >> version.
>> >> >> One way I can do this by making the onParentVersion attribute of T2
>> >> and
>> >> >> T3
>> >> >> to be IGNORE. However, in order to modify the T3 nodes, I will
>> still
>> >> >> have
>> >> >> to checkout/checkin a new version of its T1 ancestor. Is there a
>> way
>> >> to
>> >> >> avoid this?
>> >> >>
>> >> >> I understand that adding/deleting T2 nodes will have to require
>> >> checking
>> >> >> out
>> >> >> T1, since the state of T1 will have to be modified. But it seems
>> like
>> >> >> you
>> >> >> should be able to modify T2 properties and add/delete T3 nodes
>> without
>> >> >> having to do a checkout. Essentially, is there a way to make T2/T3
>> >> nodes
>> >> >> act like non-versionable standalone nodes, even though they are
>> part
>> >> of
>> >> >> the
>> >> >> node hierarchy of a versionable node?
>> >> >>
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
>> >> >> Sent from the Jackrabbit - Users mailing list archive at
>> Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > -----------------------------------------< tobias.bocanegra@day.com
>> >> >---
>> >> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001
>> Basel
>> >> > T +41 61 226 98 98, F +41 61 226 98 97
>> >> > -----------------------------------------------< http://www.day.com
>> >> >---
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
>> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > -----------------------------------------< tobias.bocanegra@day.com
>> >---
>> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>> > T +41 61 226 98 98, F +41 61 226 98 97
>> > -----------------------------------------------< http://www.day.com
>> >---
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Versioning-question-tf2633512.html#a7389860
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
>
--
View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7411240
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Versioning question
Posted by Tobias Bocanegra <to...@day.com>.
well, i'm not sure if we discussed this in the jackrabbit list or in
the jsr283 list. but since OPV=ignore properties/nodes are excluded in
the frozen state of a version anyways, they should be modifiable even
if the parent node is checked-in.
i opened a jira issue for further discussion.
http://issues.apache.org/jira/browse/JCR-639
regards, toby
On 11/16/06, James Hang <jh...@bea.com> wrote:
>
> I assume you would still need to checkout and create a new version of T1
> everytime you want to modify T2,T3 nodes. I'd like to be able to modify
> T2,T3 nodes completely indepedent of T1...
>
>
>
> Tobias Bocanegra wrote:
> >
> > so you want T2,T3:
> > - not versionable
> > - ignored by T1
> > - but not overridden on restore of T1
> >
> > but this should be possible with OPV=Ignore and 'removeExisting=false'
> > on restore.
> >
> > regards, toby
> >
> > On 11/15/06, James Hang <jh...@bea.com> wrote:
> >>
> >> What if I don't want T2 and T3 to have version history at all? So that I
> >> can
> >> modify them as independent non-versionable nodes (no checkout/checkin
> >> required). Is this possible to do? I guess maybe what might make more
> >> sense in my case is if I just put T2 and T3 nodes outside of the T1
> >> hierarchy and just have a references to them....
> >>
> >>
> >>
> >> Tobias Bocanegra wrote:
> >> >
> >> > yes, there is: you need to make them: OnParentVersion = VERSION.
> >> > this means, that their existence is recorded in version of T1 but not
> >> > there contents (if they are mix:versionable, also) i know the
> >> > versioning section in jsr170 is a bit confusing, but after having read
> >> > it 20 times, i start to understand it :-)
> >> >
> >> > regards, toby
> >> >
> >> >
> >> > On 11/15/06, James Hang <jh...@bea.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I have a question about versioning, in particular how you would create
> >> >> child
> >> >> nodes of a versioned node that are not versioned with the parent and
> >> can
> >> >> be
> >> >> modified entirely independent of its parent.
> >> >>
> >> >> For example, let's say I have a type T1. Nodes of T1 can have child
> >> nodes
> >> >> of
> >> >> type T2. Nodes of type T2 can have child nodes of type T3.
> >> >>
> >> >> So, my node tree will be like this:
> >> >>
> >> >> T1
> >> >> |_
> >> >> T2 ...
> >> >> |_
> >> >> T3 ...
> >> >>
> >> >> Now, let's say that I want to make it so that when I create a new
> >> version
> >> >> of
> >> >> T1, I don't want T2 or its descendents to be part of the state that
> >> >> version.
> >> >> One way I can do this by making the onParentVersion attribute of T2
> >> and
> >> >> T3
> >> >> to be IGNORE. However, in order to modify the T3 nodes, I will still
> >> >> have
> >> >> to checkout/checkin a new version of its T1 ancestor. Is there a way
> >> to
> >> >> avoid this?
> >> >>
> >> >> I understand that adding/deleting T2 nodes will have to require
> >> checking
> >> >> out
> >> >> T1, since the state of T1 will have to be modified. But it seems like
> >> >> you
> >> >> should be able to modify T2 properties and add/delete T3 nodes without
> >> >> having to do a checkout. Essentially, is there a way to make T2/T3
> >> nodes
> >> >> act like non-versionable standalone nodes, even though they are part
> >> of
> >> >> the
> >> >> node hierarchy of a versionable node?
> >> >>
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
> >> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > -----------------------------------------< tobias.bocanegra@day.com
> >> >---
> >> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> >> > T +41 61 226 98 98, F +41 61 226 98 97
> >> > -----------------------------------------------< http://www.day.com
> >> >---
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7389860
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Versioning question
Posted by James Hang <jh...@bea.com>.
I assume you would still need to checkout and create a new version of T1
everytime you want to modify T2,T3 nodes. I'd like to be able to modify
T2,T3 nodes completely indepedent of T1...
Tobias Bocanegra wrote:
>
> so you want T2,T3:
> - not versionable
> - ignored by T1
> - but not overridden on restore of T1
>
> but this should be possible with OPV=Ignore and 'removeExisting=false'
> on restore.
>
> regards, toby
>
> On 11/15/06, James Hang <jh...@bea.com> wrote:
>>
>> What if I don't want T2 and T3 to have version history at all? So that I
>> can
>> modify them as independent non-versionable nodes (no checkout/checkin
>> required). Is this possible to do? I guess maybe what might make more
>> sense in my case is if I just put T2 and T3 nodes outside of the T1
>> hierarchy and just have a references to them....
>>
>>
>>
>> Tobias Bocanegra wrote:
>> >
>> > yes, there is: you need to make them: OnParentVersion = VERSION.
>> > this means, that their existence is recorded in version of T1 but not
>> > there contents (if they are mix:versionable, also) i know the
>> > versioning section in jsr170 is a bit confusing, but after having read
>> > it 20 times, i start to understand it :-)
>> >
>> > regards, toby
>> >
>> >
>> > On 11/15/06, James Hang <jh...@bea.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have a question about versioning, in particular how you would create
>> >> child
>> >> nodes of a versioned node that are not versioned with the parent and
>> can
>> >> be
>> >> modified entirely independent of its parent.
>> >>
>> >> For example, let's say I have a type T1. Nodes of T1 can have child
>> nodes
>> >> of
>> >> type T2. Nodes of type T2 can have child nodes of type T3.
>> >>
>> >> So, my node tree will be like this:
>> >>
>> >> T1
>> >> |_
>> >> T2 ...
>> >> |_
>> >> T3 ...
>> >>
>> >> Now, let's say that I want to make it so that when I create a new
>> version
>> >> of
>> >> T1, I don't want T2 or its descendents to be part of the state that
>> >> version.
>> >> One way I can do this by making the onParentVersion attribute of T2
>> and
>> >> T3
>> >> to be IGNORE. However, in order to modify the T3 nodes, I will still
>> >> have
>> >> to checkout/checkin a new version of its T1 ancestor. Is there a way
>> to
>> >> avoid this?
>> >>
>> >> I understand that adding/deleting T2 nodes will have to require
>> checking
>> >> out
>> >> T1, since the state of T1 will have to be modified. But it seems like
>> >> you
>> >> should be able to modify T2 properties and add/delete T3 nodes without
>> >> having to do a checkout. Essentially, is there a way to make T2/T3
>> nodes
>> >> act like non-versionable standalone nodes, even though they are part
>> of
>> >> the
>> >> node hierarchy of a versionable node?
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
>> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > -----------------------------------------< tobias.bocanegra@day.com
>> >---
>> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>> > T +41 61 226 98 98, F +41 61 226 98 97
>> > -----------------------------------------------< http://www.day.com
>> >---
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
>
--
View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7389860
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Versioning question
Posted by Tobias Bocanegra <to...@day.com>.
so you want T2,T3:
- not versionable
- ignored by T1
- but not overridden on restore of T1
but this should be possible with OPV=Ignore and 'removeExisting=false'
on restore.
regards, toby
On 11/15/06, James Hang <jh...@bea.com> wrote:
>
> What if I don't want T2 and T3 to have version history at all? So that I can
> modify them as independent non-versionable nodes (no checkout/checkin
> required). Is this possible to do? I guess maybe what might make more
> sense in my case is if I just put T2 and T3 nodes outside of the T1
> hierarchy and just have a references to them....
>
>
>
> Tobias Bocanegra wrote:
> >
> > yes, there is: you need to make them: OnParentVersion = VERSION.
> > this means, that their existence is recorded in version of T1 but not
> > there contents (if they are mix:versionable, also) i know the
> > versioning section in jsr170 is a bit confusing, but after having read
> > it 20 times, i start to understand it :-)
> >
> > regards, toby
> >
> >
> > On 11/15/06, James Hang <jh...@bea.com> wrote:
> >>
> >> Hi,
> >>
> >> I have a question about versioning, in particular how you would create
> >> child
> >> nodes of a versioned node that are not versioned with the parent and can
> >> be
> >> modified entirely independent of its parent.
> >>
> >> For example, let's say I have a type T1. Nodes of T1 can have child nodes
> >> of
> >> type T2. Nodes of type T2 can have child nodes of type T3.
> >>
> >> So, my node tree will be like this:
> >>
> >> T1
> >> |_
> >> T2 ...
> >> |_
> >> T3 ...
> >>
> >> Now, let's say that I want to make it so that when I create a new version
> >> of
> >> T1, I don't want T2 or its descendents to be part of the state that
> >> version.
> >> One way I can do this by making the onParentVersion attribute of T2 and
> >> T3
> >> to be IGNORE. However, in order to modify the T3 nodes, I will still
> >> have
> >> to checkout/checkin a new version of its T1 ancestor. Is there a way to
> >> avoid this?
> >>
> >> I understand that adding/deleting T2 nodes will have to require checking
> >> out
> >> T1, since the state of T1 will have to be modified. But it seems like
> >> you
> >> should be able to modify T2 properties and add/delete T3 nodes without
> >> having to do a checkout. Essentially, is there a way to make T2/T3 nodes
> >> act like non-versionable standalone nodes, even though they are part of
> >> the
> >> node hierarchy of a versionable node?
> >>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Versioning question
Posted by James Hang <jh...@bea.com>.
What if I don't want T2 and T3 to have version history at all? So that I can
modify them as independent non-versionable nodes (no checkout/checkin
required). Is this possible to do? I guess maybe what might make more
sense in my case is if I just put T2 and T3 nodes outside of the T1
hierarchy and just have a references to them....
Tobias Bocanegra wrote:
>
> yes, there is: you need to make them: OnParentVersion = VERSION.
> this means, that their existence is recorded in version of T1 but not
> there contents (if they are mix:versionable, also) i know the
> versioning section in jsr170 is a bit confusing, but after having read
> it 20 times, i start to understand it :-)
>
> regards, toby
>
>
> On 11/15/06, James Hang <jh...@bea.com> wrote:
>>
>> Hi,
>>
>> I have a question about versioning, in particular how you would create
>> child
>> nodes of a versioned node that are not versioned with the parent and can
>> be
>> modified entirely independent of its parent.
>>
>> For example, let's say I have a type T1. Nodes of T1 can have child nodes
>> of
>> type T2. Nodes of type T2 can have child nodes of type T3.
>>
>> So, my node tree will be like this:
>>
>> T1
>> |_
>> T2 ...
>> |_
>> T3 ...
>>
>> Now, let's say that I want to make it so that when I create a new version
>> of
>> T1, I don't want T2 or its descendents to be part of the state that
>> version.
>> One way I can do this by making the onParentVersion attribute of T2 and
>> T3
>> to be IGNORE. However, in order to modify the T3 nodes, I will still
>> have
>> to checkout/checkin a new version of its T1 ancestor. Is there a way to
>> avoid this?
>>
>> I understand that adding/deleting T2 nodes will have to require checking
>> out
>> T1, since the state of T1 will have to be modified. But it seems like
>> you
>> should be able to modify T2 properties and add/delete T3 nodes without
>> having to do a checkout. Essentially, is there a way to make T2/T3 nodes
>> act like non-versionable standalone nodes, even though they are part of
>> the
>> node hierarchy of a versionable node?
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
>> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
>
--
View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Versioning question
Posted by Tobias Bocanegra <to...@day.com>.
yes, there is: you need to make them: OnParentVersion = VERSION.
this means, that their existence is recorded in version of T1 but not
there contents (if they are mix:versionable, also) i know the
versioning section in jsr170 is a bit confusing, but after having read
it 20 times, i start to understand it :-)
regards, toby
On 11/15/06, James Hang <jh...@bea.com> wrote:
>
> Hi,
>
> I have a question about versioning, in particular how you would create child
> nodes of a versioned node that are not versioned with the parent and can be
> modified entirely independent of its parent.
>
> For example, let's say I have a type T1. Nodes of T1 can have child nodes of
> type T2. Nodes of type T2 can have child nodes of type T3.
>
> So, my node tree will be like this:
>
> T1
> |_
> T2 ...
> |_
> T3 ...
>
> Now, let's say that I want to make it so that when I create a new version of
> T1, I don't want T2 or its descendents to be part of the state that version.
> One way I can do this by making the onParentVersion attribute of T2 and T3
> to be IGNORE. However, in order to modify the T3 nodes, I will still have
> to checkout/checkin a new version of its T1 ancestor. Is there a way to
> avoid this?
>
> I understand that adding/deleting T2 nodes will have to require checking out
> T1, since the state of T1 will have to be modified. But it seems like you
> should be able to modify T2 properties and add/delete T3 nodes without
> having to do a checkout. Essentially, is there a way to make T2/T3 nodes
> act like non-versionable standalone nodes, even though they are part of the
> node hierarchy of a versionable node?
>
>
> --
> View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---