Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Ecore Tools] Upper Bound = -2
[Ecore Tools] Upper Bound = -2 [message #105024] Sat, 22 December 2007 22:45 Go to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 306
Registered: July 2009
Senior Member
Hi.
I just learned, that Upper Bound = -2 is valid in Ecore.

It has to do with features "that can be used in features maps
corresponding to wildcards or substitution group heads. Whether the
feature will be single-valued or multi-valued will depend on the
context, i.e., on whether the wildcard or substitution group head is
itself single-valued or multi-valued." (see Eds mail below)

The TopcaseD 1.2 editor flags an error (I run it under
Eclipse 3.4m4, EMF 2.4 newest, e.t.c.)

Can this be supported by the future tools? Shall I add a feature
request, and where?

Best, Philipp


Ed Merks wrote, EMF Newsgroup 20072122 13:42
> Philipp,
>
> Comments below.
>
> Philipp W. Kutter wrote:
>> Hi.
>>
>> I am working on Birt/EMF integration, and following the EMF
>> philosophy, I try to do model based integration.
>>
>> Birt unfortunatly does not use EMF for the report editor, BUT,
>> there is the XML-Schema for the reports, and I can import it in EMF.
>>
>> The design.xsd is located in the BIRT source code in the
>> org.eclipse.birt.report.model project in the
>> src\org\eclipse\birt\report\model\parser\design.xsd file.
>> (for your convenience, I attach it)
>>
>> Now my first problem. The generated Ecore model creates
>>
>> UpperBound=-2
>>
>> for the library and report features of DocumentRoot.
> Yes, that's intentional. These features can be used in features maps
> corresponding to wildcards or substitution group heads. Whether the
> feature will be single-valued or multi-valued will depend on the
> context, i.e., on whether the wildcard or substitution group head is
> itself single-valued or multi-valued.
>>
>> The ECore validator does not flag this as error (my TopcaseD
>> editor did...)
> I'm going with Ecore's validator on this one. :-P
>>
>> Is this valid ECore? Is this a valid Schema?
> According to the XSD validator, the schema is valid, and according to
> our Ecore validator, the resulting Ecore is correct as well.
>
> I wonder if the BIRT guys hand wrote an API for this large schema-based
> model? Seems like a lot of work for something you can do with the push
> of a button...
>>
>> Best Regards, Philipp
Re: [Ecore Tools] Upper Bound = -2 [message #105025 is a reply to message #105024] Sun, 23 December 2007 01:05 Go to previous messageGo to next message
lucas bigeardel is currently offline lucas bigeardelFriend
Messages: 155
Registered: July 2009
Senior Member
Phillip,

you can submit RFEs for ecoretools here :
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;bug_severity=enhancement

select Ecore Tools as the component your RFE to be targeted to.


cheers,





Philipp W. Kutter a écrit :
> Hi.
> I just learned, that Upper Bound = -2 is valid in Ecore.
>
> It has to do with features "that can be used in features maps
> corresponding to wildcards or substitution group heads. Whether the
> feature will be single-valued or multi-valued will depend on the
> context, i.e., on whether the wildcard or substitution group head is
> itself single-valued or multi-valued." (see Eds mail below)
>
> The TopcaseD 1.2 editor flags an error (I run it under
> Eclipse 3.4m4, EMF 2.4 newest, e.t.c.)
>
> Can this be supported by the future tools? Shall I add a feature
> request, and where?
>
> Best, Philipp
>
>
> Ed Merks wrote, EMF Newsgroup 20072122 13:42
> > Philipp,
> >
> > Comments below.
> >
> > Philipp W. Kutter wrote:
> >> Hi.
> >>
> >> I am working on Birt/EMF integration, and following the EMF
> >> philosophy, I try to do model based integration.
> >>
> >> Birt unfortunatly does not use EMF for the report editor, BUT,
> >> there is the XML-Schema for the reports, and I can import it in EMF.
> >>
> >> The design.xsd is located in the BIRT source code in the
> >> org.eclipse.birt.report.model project in the
> >> src\org\eclipse\birt\report\model\parser\design.xsd file.
> >> (for your convenience, I attach it)
> >>
> >> Now my first problem. The generated Ecore model creates
> >>
> >> UpperBound=-2
> >>
> >> for the library and report features of DocumentRoot.
> > Yes, that's intentional. These features can be used in features maps
> > corresponding to wildcards or substitution group heads. Whether the
> > feature will be single-valued or multi-valued will depend on the
> > context, i.e., on whether the wildcard or substitution group head is
> > itself single-valued or multi-valued.
> >>
> >> The ECore validator does not flag this as error (my TopcaseD
> >> editor did...)
> > I'm going with Ecore's validator on this one. :-P
> >>
> >> Is this valid ECore? Is this a valid Schema?
> > According to the XSD validator, the schema is valid, and according to
> > our Ecore validator, the resulting Ecore is correct as well.
> >
> > I wonder if the BIRT guys hand wrote an API for this large schema-based
> > model? Seems like a lot of work for something you can do with the push
> > of a button...
> >>
> >> Best Regards, Philipp
Re: [Ecore Tools] Upper Bound = -2 [message #105117 is a reply to message #105025] Sun, 23 December 2007 12:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Lucas,

I guess I should really have a look at how the validation provided there
is different from what's provided directly by EcoreValidator itself.
I'm more than happy to look at adding anything missing from
EcoreValidator so it could be reused directly. (There are quite a few
tricky constraints with respect to the generics.)


lucas bigeardel wrote:
> Phillip,
>
> you can submit RFEs for ecoretools here :
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;bug_severity=enhancement
>
>
> select Ecore Tools as the component your RFE to be targeted to.
>
>
> cheers,
>
>
>
>
>
> Philipp W. Kutter a écrit :
>> Hi.
>> I just learned, that Upper Bound = -2 is valid in Ecore.
>>
>> It has to do with features "that can be used in features maps
>> corresponding to wildcards or substitution group heads. Whether the
>> feature will be single-valued or multi-valued will depend on the
>> context, i.e., on whether the wildcard or substitution group head is
>> itself single-valued or multi-valued." (see Eds mail below)
>>
>> The TopcaseD 1.2 editor flags an error (I run it under
>> Eclipse 3.4m4, EMF 2.4 newest, e.t.c.)
>>
>> Can this be supported by the future tools? Shall I add a feature
>> request, and where?
>>
>> Best, Philipp
>>
>>
>> Ed Merks wrote, EMF Newsgroup 20072122 13:42
>> > Philipp,
>> >
>> > Comments below.
>> >
>> > Philipp W. Kutter wrote:
>> >> Hi.
>> >>
>> >> I am working on Birt/EMF integration, and following the EMF
>> >> philosophy, I try to do model based integration.
>> >>
>> >> Birt unfortunatly does not use EMF for the report editor, BUT,
>> >> there is the XML-Schema for the reports, and I can import it in EMF.
>> >>
>> >> The design.xsd is located in the BIRT source code in the
>> >> org.eclipse.birt.report.model project in the
>> >> src\org\eclipse\birt\report\model\parser\design.xsd file.
>> >> (for your convenience, I attach it)
>> >>
>> >> Now my first problem. The generated Ecore model creates
>> >>
>> >> UpperBound=-2
>> >>
>> >> for the library and report features of DocumentRoot.
>> > Yes, that's intentional. These features can be used in features maps
>> > corresponding to wildcards or substitution group heads. Whether the
>> > feature will be single-valued or multi-valued will depend on the
>> > context, i.e., on whether the wildcard or substitution group head is
>> > itself single-valued or multi-valued.
>> >>
>> >> The ECore validator does not flag this as error (my TopcaseD
>> >> editor did...)
>> > I'm going with Ecore's validator on this one. :-P
>> >>
>> >> Is this valid ECore? Is this a valid Schema?
>> > According to the XSD validator, the schema is valid, and according to
>> > our Ecore validator, the resulting Ecore is correct as well.
>> >
>> > I wonder if the BIRT guys hand wrote an API for this large
>> schema-based
>> > model? Seems like a lot of work for something you can do with the
>> push
>> > of a button...
>> >>
>> >> Best Regards, Philipp
Re: [Ecore Tools] Upper Bound = -2 [message #105143 is a reply to message #105117] Sun, 23 December 2007 16:40 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 306
Registered: July 2009
Senior Member
Ed, I added your comment to the corresponding feature request.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785

The Ecore Tools peopls may want to create one for "reusing
EcoreValidator" and mark mine as duplicate.


Ed Merks wrote:
> Lucas,
>
> I guess I should really have a look at how the validation provided there
> is different from what's provided directly by EcoreValidator itself.
> I'm more than happy to look at adding anything missing from
> EcoreValidator so it could be reused directly. (There are quite a few
> tricky constraints with respect to the generics.)
>
>
Re: [Ecore Tools] Upper Bound = -2 [message #105225 is a reply to message #105143] Wed, 26 December 2007 10:11 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 306
Registered: July 2009
Senior Member
Ecore Tools people: shall I open the feature request?

Best, Philipp

Philipp W. Kutter wrote:
> Ed, I added your comment to the corresponding feature request.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>
> The Ecore Tools peopls may want to create one for "reusing
> EcoreValidator" and mark mine as duplicate.
>
>
> Ed Merks wrote:
>> Lucas,
>>
>> I guess I should really have a look at how the validation provided
>> there is different from what's provided directly by EcoreValidator
>> itself. I'm more than happy to look at adding anything missing from
>> EcoreValidator so it could be reused directly. (There are quite a few
>> tricky constraints with respect to the generics.)
>>
>>
Re: [Ecore Tools] Upper Bound = -2 [message #105587 is a reply to message #105225] Wed, 02 January 2008 10:25 Go to previous messageGo to next message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
HAPPY NEW YEAR !! :-)

Philipp,

I don't think this is necessary to open a new feature request, as while
testing on my own, the Validation is correct ('-2' as a upper bound is
valid, '-3' not).
Since we have enabled validation on the Ecore Tools diagram, it uses the
default EcoreValidator : GMF generated all the necessary stuff. We
haven't forked the validation process to provide our own validator.

Ed and others,

I wonder how we could graphically represent the EReference multiplicity
when the upper bound is '-2' ?
For '-1' we display a star ('*') and for now, the same is used when
upper bound is set as '-2'.
In the Tree editor I noticed that the icon used when setting the upper
bound as '-2' was the one showing 'n..m' : I wonder whether this is a
bug or not ? Should we use a similar thing ?

Regards,
Jacques

Philipp W. Kutter a écrit :
> Ecore Tools people: shall I open the feature request?
>
> Best, Philipp
>
> Philipp W. Kutter wrote:
>> Ed, I added your comment to the corresponding feature request.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>
>> The Ecore Tools peopls may want to create one for "reusing
>> EcoreValidator" and mark mine as duplicate.
>>
>>
>> Ed Merks wrote:
>>> Lucas,
>>>
>>> I guess I should really have a look at how the validation provided
>>> there is different from what's provided directly by EcoreValidator
>>> itself. I'm more than happy to look at adding anything missing from
>>> EcoreValidator so it could be reused directly. (There are quite a
>>> few tricky constraints with respect to the generics.)
>>>
>>>
Re: [Ecore Tools] Upper Bound = -2 [message #105600 is a reply to message #105143] Wed, 02 January 2008 10:38 Go to previous messageGo to next message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
Philipp,

after reading agin more attentively your request, I noticed that you
were talking of the Topcased 1.2 version. In this version, I could
reproduce the bug you are talking about, but this is not related to the
Ecore Tools component at all.

For your information, Topcased 1.x releases are still compliant with
Eclipse 3.3 (Europa) and contains the Ecore editor developped among the
Topcased project, not generated using GMF. So bugs related to this
version should be open towards the Topcased bugtracker.

Topcased 2.x releases are compliant with Eclipse 3.4 milestones and
contains here the Ecore editor available in the Ecore Tools component.
Currently the version is in a early development state, and if you want
to test the Ecore Tools editor on your own, you can probably use the
latest version available here :
http://www.eclipse.org/modeling/emft/downloads/?project=ecor etools

Sorry for the misunderstanding

Best regards,
Jacques

Philipp W. Kutter a écrit :
> Ed, I added your comment to the corresponding feature request.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>
> The Ecore Tools peopls may want to create one for "reusing
> EcoreValidator" and mark mine as duplicate.
>
>
> Ed Merks wrote:
>> Lucas,
>>
>> I guess I should really have a look at how the validation provided
>> there is different from what's provided directly by EcoreValidator
>> itself. I'm more than happy to look at adding anything missing from
>> EcoreValidator so it could be reused directly. (There are quite a few
>> tricky constraints with respect to the generics.)
>>
>>
Re: [Ecore Tools] Upper Bound = -2 [message #105626 is a reply to message #105587] Wed, 02 January 2008 12:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

This is a multi-part message in MIME format.
--------------060302020009060105040205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jacques,

I'm not sure that n..m is the best thing to display either; we do that
whenever the upper bound isn't 1 or -1 or the lower bound isn't 0 or 1,
i.e., when none of the other simpler (more usual) icons apply.
Technically the -2 indicates unspecified as defined by this
ETypedElement constant:

/**
* A value indicating that there is an unspecified {@link
#getUpperBound upper bound}.
* @see #getUpperBound()
*/
int UNSPECIFIED_MULTIPLICITY = -2;

So perhaps something like 0..? would be more appropriate. The existing
icons predated the use of -2. Then again, n..m does seem reasonable
though it doesn't make the fact that m is the special value -2 at all
clear. Any suggestions for improvements are more than welcome! I'm
more than happy to agree on something better and make corresponding
changes in Sample Ecore Editor...


Jacques LESCOT wrote:
> HAPPY NEW YEAR !! :-)
>
> Philipp,
>
> I don't think this is necessary to open a new feature request, as
> while testing on my own, the Validation is correct ('-2' as a upper
> bound is valid, '-3' not).
> Since we have enabled validation on the Ecore Tools diagram, it uses
> the default EcoreValidator : GMF generated all the necessary stuff. We
> haven't forked the validation process to provide our own validator.
>
> Ed and others,
>
> I wonder how we could graphically represent the EReference
> multiplicity when the upper bound is '-2' ?
> For '-1' we display a star ('*') and for now, the same is used when
> upper bound is set as '-2'.
> In the Tree editor I noticed that the icon used when setting the upper
> bound as '-2' was the one showing 'n..m' : I wonder whether this is a
> bug or not ? Should we use a similar thing ?
>
> Regards,
> Jacques
>
> Philipp W. Kutter a
Re: [Ecore Tools] Upper Bound = -2 [message #105658 is a reply to message #105626] Wed, 02 January 2008 14:00 Go to previous messageGo to next message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
I was also thinking to display '?' when the feature is set as '-2'.

Ed Merks a écrit :
> Jacques,
>
> I'm not sure that n..m is the best thing to display either; we do that
> whenever the upper bound isn't 1 or -1 or the lower bound isn't 0 or 1,
> i.e., when none of the other simpler (more usual) icons apply.
> Technically the -2 indicates unspecified as defined by this
> ETypedElement constant:
>
> /**
> * A value indicating that there is an unspecified {@link
> #getUpperBound upper bound}.
> * @see #getUpperBound()
> */
> int UNSPECIFIED_MULTIPLICITY = -2;
>
> So perhaps something like 0..? would be more appropriate. The existing
> icons predated the use of -2. Then again, n..m does seem reasonable
> though it doesn't make the fact that m is the special value -2 at all
> clear. Any suggestions for improvements are more than welcome! I'm
> more than happy to agree on something better and make corresponding
> changes in Sample Ecore Editor...
>
>
> Jacques LESCOT wrote:
>> HAPPY NEW YEAR !! :-)
>>
>> Philipp,
>>
>> I don't think this is necessary to open a new feature request, as
>> while testing on my own, the Validation is correct ('-2' as a upper
>> bound is valid, '-3' not).
>> Since we have enabled validation on the Ecore Tools diagram, it uses
>> the default EcoreValidator : GMF generated all the necessary stuff. We
>> haven't forked the validation process to provide our own validator.
>>
>> Ed and others,
>>
>> I wonder how we could graphically represent the EReference
>> multiplicity when the upper bound is '-2' ?
>> For '-1' we display a star ('*') and for now, the same is used when
>> upper bound is set as '-2'.
>> In the Tree editor I noticed that the icon used when setting the upper
>> bound as '-2' was the one showing 'n..m' : I wonder whether this is a
>> bug or not ? Should we use a similar thing ?
>>
>> Regards,
>> Jacques
>>
>> Philipp W. Kutter a écrit :
>>> Ecore Tools people: shall I open the feature request?
>>>
>>> Best, Philipp
>>>
>>> Philipp W. Kutter wrote:
>>>> Ed, I added your comment to the corresponding feature request.
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>
>>>> The Ecore Tools peopls may want to create one for "reusing
>>>> EcoreValidator" and mark mine as duplicate.
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Lucas,
>>>>>
>>>>> I guess I should really have a look at how the validation provided
>>>>> there is different from what's provided directly by EcoreValidator
>>>>> itself. I'm more than happy to look at adding anything missing
>>>>> from EcoreValidator so it could be reused directly. (There are
>>>>> quite a few tricky constraints with respect to the generics.)
>>>>>
>>>>>
>
Re: [Ecore Tools] Upper Bound = -2 [message #105673 is a reply to message #105658] Wed, 02 January 2008 14:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Jacques,

Please open an enhancement request and we'll use it to to prompt us to
get the graphic designers to create a new icon for us.


Jacques LESCOT wrote:
> I was also thinking to display '?' when the feature is set as '-2'.
>
> Ed Merks a écrit :
>> Jacques,
>>
>> I'm not sure that n..m is the best thing to display either; we do
>> that whenever the upper bound isn't 1 or -1 or the lower bound isn't
>> 0 or 1, i.e., when none of the other simpler (more usual) icons
>> apply. Technically the -2 indicates unspecified as defined by this
>> ETypedElement constant:
>>
>> /**
>> * A value indicating that there is an unspecified {@link
>> #getUpperBound upper bound}.
>> * @see #getUpperBound()
>> */
>> int UNSPECIFIED_MULTIPLICITY = -2;
>>
>> So perhaps something like 0..? would be more appropriate. The
>> existing icons predated the use of -2. Then again, n..m does seem
>> reasonable though it doesn't make the fact that m is the special
>> value -2 at all clear. Any suggestions for improvements are more
>> than welcome! I'm more than happy to agree on something better and
>> make corresponding changes in Sample Ecore Editor...
>>
>>
>> Jacques LESCOT wrote:
>>> HAPPY NEW YEAR !! :-)
>>>
>>> Philipp,
>>>
>>> I don't think this is necessary to open a new feature request, as
>>> while testing on my own, the Validation is correct ('-2' as a upper
>>> bound is valid, '-3' not).
>>> Since we have enabled validation on the Ecore Tools diagram, it uses
>>> the default EcoreValidator : GMF generated all the necessary stuff.
>>> We haven't forked the validation process to provide our own validator.
>>>
>>> Ed and others,
>>>
>>> I wonder how we could graphically represent the EReference
>>> multiplicity when the upper bound is '-2' ?
>>> For '-1' we display a star ('*') and for now, the same is used when
>>> upper bound is set as '-2'.
>>> In the Tree editor I noticed that the icon used when setting the
>>> upper bound as '-2' was the one showing 'n..m' : I wonder whether
>>> this is a bug or not ? Should we use a similar thing ?
>>>
>>> Regards,
>>> Jacques
>>>
>>> Philipp W. Kutter a écrit :
>>>> Ecore Tools people: shall I open the feature request?
>>>>
>>>> Best, Philipp
>>>>
>>>> Philipp W. Kutter wrote:
>>>>> Ed, I added your comment to the corresponding feature request.
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>>
>>>>> The Ecore Tools peopls may want to create one for "reusing
>>>>> EcoreValidator" and mark mine as duplicate.
>>>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Lucas,
>>>>>>
>>>>>> I guess I should really have a look at how the validation
>>>>>> provided there is different from what's provided directly by
>>>>>> EcoreValidator itself. I'm more than happy to look at adding
>>>>>> anything missing from EcoreValidator so it could be reused
>>>>>> directly. (There are quite a few tricky constraints with respect
>>>>>> to the generics.)
>>>>>>
>>>>>>
>>
Re: [Ecore Tools] Upper Bound = -2 [message #105695 is a reply to message #105673] Wed, 02 January 2008 15:52 Go to previous message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
Done.

Link to the enhancement request :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214120

Ed Merks a écrit :
> Jacques,
>
> Please open an enhancement request and we'll use it to to prompt us to
> get the graphic designers to create a new icon for us.
>
>
> Jacques LESCOT wrote:
>> I was also thinking to display '?' when the feature is set as '-2'.
>>
>> Ed Merks a écrit :
>>> Jacques,
>>>
>>> I'm not sure that n..m is the best thing to display either; we do
>>> that whenever the upper bound isn't 1 or -1 or the lower bound isn't
>>> 0 or 1, i.e., when none of the other simpler (more usual) icons
>>> apply. Technically the -2 indicates unspecified as defined by this
>>> ETypedElement constant:
>>>
>>> /**
>>> * A value indicating that there is an unspecified {@link
>>> #getUpperBound upper bound}.
>>> * @see #getUpperBound()
>>> */
>>> int UNSPECIFIED_MULTIPLICITY = -2;
>>>
>>> So perhaps something like 0..? would be more appropriate. The
>>> existing icons predated the use of -2. Then again, n..m does seem
>>> reasonable though it doesn't make the fact that m is the special
>>> value -2 at all clear. Any suggestions for improvements are more
>>> than welcome! I'm more than happy to agree on something better and
>>> make corresponding changes in Sample Ecore Editor...
>>>
>>>
>>> Jacques LESCOT wrote:
>>>> HAPPY NEW YEAR !! :-)
>>>>
>>>> Philipp,
>>>>
>>>> I don't think this is necessary to open a new feature request, as
>>>> while testing on my own, the Validation is correct ('-2' as a upper
>>>> bound is valid, '-3' not).
>>>> Since we have enabled validation on the Ecore Tools diagram, it uses
>>>> the default EcoreValidator : GMF generated all the necessary stuff.
>>>> We haven't forked the validation process to provide our own validator.
>>>>
>>>> Ed and others,
>>>>
>>>> I wonder how we could graphically represent the EReference
>>>> multiplicity when the upper bound is '-2' ?
>>>> For '-1' we display a star ('*') and for now, the same is used when
>>>> upper bound is set as '-2'.
>>>> In the Tree editor I noticed that the icon used when setting the
>>>> upper bound as '-2' was the one showing 'n..m' : I wonder whether
>>>> this is a bug or not ? Should we use a similar thing ?
>>>>
>>>> Regards,
>>>> Jacques
>>>>
>>>> Philipp W. Kutter a écrit :
>>>>> Ecore Tools people: shall I open the feature request?
>>>>>
>>>>> Best, Philipp
>>>>>
>>>>> Philipp W. Kutter wrote:
>>>>>> Ed, I added your comment to the corresponding feature request.
>>>>>>
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>>>
>>>>>> The Ecore Tools peopls may want to create one for "reusing
>>>>>> EcoreValidator" and mark mine as duplicate.
>>>>>>
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Lucas,
>>>>>>>
>>>>>>> I guess I should really have a look at how the validation
>>>>>>> provided there is different from what's provided directly by
>>>>>>> EcoreValidator itself. I'm more than happy to look at adding
>>>>>>> anything missing from EcoreValidator so it could be reused
>>>>>>> directly. (There are quite a few tricky constraints with respect
>>>>>>> to the generics.)
>>>>>>>
>>>>>>>
>>>
Re: [Ecore Tools] Upper Bound = -2 [message #612979 is a reply to message #105024] Sun, 23 December 2007 01:05 Go to previous message
lucas bigeardel is currently offline lucas bigeardelFriend
Messages: 155
Registered: July 2009
Senior Member
Phillip,

you can submit RFEs for ecoretools here :
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;bug_severity=enhancement

select Ecore Tools as the component your RFE to be targeted to.


cheers,





Philipp W. Kutter a écrit :
> Hi.
> I just learned, that Upper Bound = -2 is valid in Ecore.
>
> It has to do with features "that can be used in features maps
> corresponding to wildcards or substitution group heads. Whether the
> feature will be single-valued or multi-valued will depend on the
> context, i.e., on whether the wildcard or substitution group head is
> itself single-valued or multi-valued." (see Eds mail below)
>
> The TopcaseD 1.2 editor flags an error (I run it under
> Eclipse 3.4m4, EMF 2.4 newest, e.t.c.)
>
> Can this be supported by the future tools? Shall I add a feature
> request, and where?
>
> Best, Philipp
>
>
> Ed Merks wrote, EMF Newsgroup 20072122 13:42
> > Philipp,
> >
> > Comments below.
> >
> > Philipp W. Kutter wrote:
> >> Hi.
> >>
> >> I am working on Birt/EMF integration, and following the EMF
> >> philosophy, I try to do model based integration.
> >>
> >> Birt unfortunatly does not use EMF for the report editor, BUT,
> >> there is the XML-Schema for the reports, and I can import it in EMF.
> >>
> >> The design.xsd is located in the BIRT source code in the
> >> org.eclipse.birt.report.model project in the
> >> src\org\eclipse\birt\report\model\parser\design.xsd file.
> >> (for your convenience, I attach it)
> >>
> >> Now my first problem. The generated Ecore model creates
> >>
> >> UpperBound=-2
> >>
> >> for the library and report features of DocumentRoot.
> > Yes, that's intentional. These features can be used in features maps
> > corresponding to wildcards or substitution group heads. Whether the
> > feature will be single-valued or multi-valued will depend on the
> > context, i.e., on whether the wildcard or substitution group head is
> > itself single-valued or multi-valued.
> >>
> >> The ECore validator does not flag this as error (my TopcaseD
> >> editor did...)
> > I'm going with Ecore's validator on this one. :-P
> >>
> >> Is this valid ECore? Is this a valid Schema?
> > According to the XSD validator, the schema is valid, and according to
> > our Ecore validator, the resulting Ecore is correct as well.
> >
> > I wonder if the BIRT guys hand wrote an API for this large schema-based
> > model? Seems like a lot of work for something you can do with the push
> > of a button...
> >>
> >> Best Regards, Philipp
Re: [Ecore Tools] Upper Bound = -2 [message #612990 is a reply to message #105025] Sun, 23 December 2007 12:27 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31467
Registered: July 2009
Senior Member
Lucas,

I guess I should really have a look at how the validation provided there
is different from what's provided directly by EcoreValidator itself.
I'm more than happy to look at adding anything missing from
EcoreValidator so it could be reused directly. (There are quite a few
tricky constraints with respect to the generics.)


lucas bigeardel wrote:
> Phillip,
>
> you can submit RFEs for ecoretools here :
> https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT& ;bug_severity=enhancement
>
>
> select Ecore Tools as the component your RFE to be targeted to.
>
>
> cheers,
>
>
>
>
>
> Philipp W. Kutter a écrit :
>> Hi.
>> I just learned, that Upper Bound = -2 is valid in Ecore.
>>
>> It has to do with features "that can be used in features maps
>> corresponding to wildcards or substitution group heads. Whether the
>> feature will be single-valued or multi-valued will depend on the
>> context, i.e., on whether the wildcard or substitution group head is
>> itself single-valued or multi-valued." (see Eds mail below)
>>
>> The TopcaseD 1.2 editor flags an error (I run it under
>> Eclipse 3.4m4, EMF 2.4 newest, e.t.c.)
>>
>> Can this be supported by the future tools? Shall I add a feature
>> request, and where?
>>
>> Best, Philipp
>>
>>
>> Ed Merks wrote, EMF Newsgroup 20072122 13:42
>> > Philipp,
>> >
>> > Comments below.
>> >
>> > Philipp W. Kutter wrote:
>> >> Hi.
>> >>
>> >> I am working on Birt/EMF integration, and following the EMF
>> >> philosophy, I try to do model based integration.
>> >>
>> >> Birt unfortunatly does not use EMF for the report editor, BUT,
>> >> there is the XML-Schema for the reports, and I can import it in EMF.
>> >>
>> >> The design.xsd is located in the BIRT source code in the
>> >> org.eclipse.birt.report.model project in the
>> >> src\org\eclipse\birt\report\model\parser\design.xsd file.
>> >> (for your convenience, I attach it)
>> >>
>> >> Now my first problem. The generated Ecore model creates
>> >>
>> >> UpperBound=-2
>> >>
>> >> for the library and report features of DocumentRoot.
>> > Yes, that's intentional. These features can be used in features maps
>> > corresponding to wildcards or substitution group heads. Whether the
>> > feature will be single-valued or multi-valued will depend on the
>> > context, i.e., on whether the wildcard or substitution group head is
>> > itself single-valued or multi-valued.
>> >>
>> >> The ECore validator does not flag this as error (my TopcaseD
>> >> editor did...)
>> > I'm going with Ecore's validator on this one. :-P
>> >>
>> >> Is this valid ECore? Is this a valid Schema?
>> > According to the XSD validator, the schema is valid, and according to
>> > our Ecore validator, the resulting Ecore is correct as well.
>> >
>> > I wonder if the BIRT guys hand wrote an API for this large
>> schema-based
>> > model? Seems like a lot of work for something you can do with the
>> push
>> > of a button...
>> >>
>> >> Best Regards, Philipp


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Ecore Tools] Upper Bound = -2 [message #612994 is a reply to message #105117] Sun, 23 December 2007 16:40 Go to previous message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 306
Registered: July 2009
Senior Member
Ed, I added your comment to the corresponding feature request.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785

The Ecore Tools peopls may want to create one for "reusing
EcoreValidator" and mark mine as duplicate.


Ed Merks wrote:
> Lucas,
>
> I guess I should really have a look at how the validation provided there
> is different from what's provided directly by EcoreValidator itself.
> I'm more than happy to look at adding anything missing from
> EcoreValidator so it could be reused directly. (There are quite a few
> tricky constraints with respect to the generics.)
>
>
Re: [Ecore Tools] Upper Bound = -2 [message #613005 is a reply to message #105143] Wed, 26 December 2007 10:11 Go to previous message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 306
Registered: July 2009
Senior Member
Ecore Tools people: shall I open the feature request?

Best, Philipp

Philipp W. Kutter wrote:
> Ed, I added your comment to the corresponding feature request.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>
> The Ecore Tools peopls may want to create one for "reusing
> EcoreValidator" and mark mine as duplicate.
>
>
> Ed Merks wrote:
>> Lucas,
>>
>> I guess I should really have a look at how the validation provided
>> there is different from what's provided directly by EcoreValidator
>> itself. I'm more than happy to look at adding anything missing from
>> EcoreValidator so it could be reused directly. (There are quite a few
>> tricky constraints with respect to the generics.)
>>
>>
Re: [Ecore Tools] Upper Bound = -2 [message #613056 is a reply to message #105225] Wed, 02 January 2008 10:25 Go to previous message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
HAPPY NEW YEAR !! :-)

Philipp,

I don't think this is necessary to open a new feature request, as while
testing on my own, the Validation is correct ('-2' as a upper bound is
valid, '-3' not).
Since we have enabled validation on the Ecore Tools diagram, it uses the
default EcoreValidator : GMF generated all the necessary stuff. We
haven't forked the validation process to provide our own validator.

Ed and others,

I wonder how we could graphically represent the EReference multiplicity
when the upper bound is '-2' ?
For '-1' we display a star ('*') and for now, the same is used when
upper bound is set as '-2'.
In the Tree editor I noticed that the icon used when setting the upper
bound as '-2' was the one showing 'n..m' : I wonder whether this is a
bug or not ? Should we use a similar thing ?

Regards,
Jacques

Philipp W. Kutter a écrit :
> Ecore Tools people: shall I open the feature request?
>
> Best, Philipp
>
> Philipp W. Kutter wrote:
>> Ed, I added your comment to the corresponding feature request.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>
>> The Ecore Tools peopls may want to create one for "reusing
>> EcoreValidator" and mark mine as duplicate.
>>
>>
>> Ed Merks wrote:
>>> Lucas,
>>>
>>> I guess I should really have a look at how the validation provided
>>> there is different from what's provided directly by EcoreValidator
>>> itself. I'm more than happy to look at adding anything missing from
>>> EcoreValidator so it could be reused directly. (There are quite a
>>> few tricky constraints with respect to the generics.)
>>>
>>>
Re: [Ecore Tools] Upper Bound = -2 [message #613057 is a reply to message #105143] Wed, 02 January 2008 10:38 Go to previous message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
Philipp,

after reading agin more attentively your request, I noticed that you
were talking of the Topcased 1.2 version. In this version, I could
reproduce the bug you are talking about, but this is not related to the
Ecore Tools component at all.

For your information, Topcased 1.x releases are still compliant with
Eclipse 3.3 (Europa) and contains the Ecore editor developped among the
Topcased project, not generated using GMF. So bugs related to this
version should be open towards the Topcased bugtracker.

Topcased 2.x releases are compliant with Eclipse 3.4 milestones and
contains here the Ecore editor available in the Ecore Tools component.
Currently the version is in a early development state, and if you want
to test the Ecore Tools editor on your own, you can probably use the
latest version available here :
http://www.eclipse.org/modeling/emft/downloads/?project=ecor etools

Sorry for the misunderstanding

Best regards,
Jacques

Philipp W. Kutter a écrit :
> Ed, I added your comment to the corresponding feature request.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>
> The Ecore Tools peopls may want to create one for "reusing
> EcoreValidator" and mark mine as duplicate.
>
>
> Ed Merks wrote:
>> Lucas,
>>
>> I guess I should really have a look at how the validation provided
>> there is different from what's provided directly by EcoreValidator
>> itself. I'm more than happy to look at adding anything missing from
>> EcoreValidator so it could be reused directly. (There are quite a few
>> tricky constraints with respect to the generics.)
>>
>>
Re: [Ecore Tools] Upper Bound = -2 [message #613059 is a reply to message #105587] Wed, 02 January 2008 12:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31467
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060302020009060105040205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jacques,

I'm not sure that n..m is the best thing to display either; we do that
whenever the upper bound isn't 1 or -1 or the lower bound isn't 0 or 1,
i.e., when none of the other simpler (more usual) icons apply.
Technically the -2 indicates unspecified as defined by this
ETypedElement constant:

/**
* A value indicating that there is an unspecified {@link
#getUpperBound upper bound}.
* @see #getUpperBound()
*/
int UNSPECIFIED_MULTIPLICITY = -2;

So perhaps something like 0..? would be more appropriate. The existing
icons predated the use of -2. Then again, n..m does seem reasonable
though it doesn't make the fact that m is the special value -2 at all
clear. Any suggestions for improvements are more than welcome! I'm
more than happy to agree on something better and make corresponding
changes in Sample Ecore Editor...


Jacques LESCOT wrote:
> HAPPY NEW YEAR !! :-)
>
> Philipp,
>
> I don't think this is necessary to open a new feature request, as
> while testing on my own, the Validation is correct ('-2' as a upper
> bound is valid, '-3' not).
> Since we have enabled validation on the Ecore Tools diagram, it uses
> the default EcoreValidator : GMF generated all the necessary stuff. We
> haven't forked the validation process to provide our own validator.
>
> Ed and others,
>
> I wonder how we could graphically represent the EReference
> multiplicity when the upper bound is '-2' ?
> For '-1' we display a star ('*') and for now, the same is used when
> upper bound is set as '-2'.
> In the Tree editor I noticed that the icon used when setting the upper
> bound as '-2' was the one showing 'n..m' : I wonder whether this is a
> bug or not ? Should we use a similar thing ?
>
> Regards,
> Jacques
>
> Philipp W. Kutter a


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Ecore Tools] Upper Bound = -2 [message #613061 is a reply to message #105626] Wed, 02 January 2008 14:00 Go to previous message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
I was also thinking to display '?' when the feature is set as '-2'.

Ed Merks a écrit :
> Jacques,
>
> I'm not sure that n..m is the best thing to display either; we do that
> whenever the upper bound isn't 1 or -1 or the lower bound isn't 0 or 1,
> i.e., when none of the other simpler (more usual) icons apply.
> Technically the -2 indicates unspecified as defined by this
> ETypedElement constant:
>
> /**
> * A value indicating that there is an unspecified {@link
> #getUpperBound upper bound}.
> * @see #getUpperBound()
> */
> int UNSPECIFIED_MULTIPLICITY = -2;
>
> So perhaps something like 0..? would be more appropriate. The existing
> icons predated the use of -2. Then again, n..m does seem reasonable
> though it doesn't make the fact that m is the special value -2 at all
> clear. Any suggestions for improvements are more than welcome! I'm
> more than happy to agree on something better and make corresponding
> changes in Sample Ecore Editor...
>
>
> Jacques LESCOT wrote:
>> HAPPY NEW YEAR !! :-)
>>
>> Philipp,
>>
>> I don't think this is necessary to open a new feature request, as
>> while testing on my own, the Validation is correct ('-2' as a upper
>> bound is valid, '-3' not).
>> Since we have enabled validation on the Ecore Tools diagram, it uses
>> the default EcoreValidator : GMF generated all the necessary stuff. We
>> haven't forked the validation process to provide our own validator.
>>
>> Ed and others,
>>
>> I wonder how we could graphically represent the EReference
>> multiplicity when the upper bound is '-2' ?
>> For '-1' we display a star ('*') and for now, the same is used when
>> upper bound is set as '-2'.
>> In the Tree editor I noticed that the icon used when setting the upper
>> bound as '-2' was the one showing 'n..m' : I wonder whether this is a
>> bug or not ? Should we use a similar thing ?
>>
>> Regards,
>> Jacques
>>
>> Philipp W. Kutter a écrit :
>>> Ecore Tools people: shall I open the feature request?
>>>
>>> Best, Philipp
>>>
>>> Philipp W. Kutter wrote:
>>>> Ed, I added your comment to the corresponding feature request.
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>
>>>> The Ecore Tools peopls may want to create one for "reusing
>>>> EcoreValidator" and mark mine as duplicate.
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Lucas,
>>>>>
>>>>> I guess I should really have a look at how the validation provided
>>>>> there is different from what's provided directly by EcoreValidator
>>>>> itself. I'm more than happy to look at adding anything missing
>>>>> from EcoreValidator so it could be reused directly. (There are
>>>>> quite a few tricky constraints with respect to the generics.)
>>>>>
>>>>>
>
Re: [Ecore Tools] Upper Bound = -2 [message #613062 is a reply to message #105658] Wed, 02 January 2008 14:09 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31467
Registered: July 2009
Senior Member
Jacques,

Please open an enhancement request and we'll use it to to prompt us to
get the graphic designers to create a new icon for us.


Jacques LESCOT wrote:
> I was also thinking to display '?' when the feature is set as '-2'.
>
> Ed Merks a écrit :
>> Jacques,
>>
>> I'm not sure that n..m is the best thing to display either; we do
>> that whenever the upper bound isn't 1 or -1 or the lower bound isn't
>> 0 or 1, i.e., when none of the other simpler (more usual) icons
>> apply. Technically the -2 indicates unspecified as defined by this
>> ETypedElement constant:
>>
>> /**
>> * A value indicating that there is an unspecified {@link
>> #getUpperBound upper bound}.
>> * @see #getUpperBound()
>> */
>> int UNSPECIFIED_MULTIPLICITY = -2;
>>
>> So perhaps something like 0..? would be more appropriate. The
>> existing icons predated the use of -2. Then again, n..m does seem
>> reasonable though it doesn't make the fact that m is the special
>> value -2 at all clear. Any suggestions for improvements are more
>> than welcome! I'm more than happy to agree on something better and
>> make corresponding changes in Sample Ecore Editor...
>>
>>
>> Jacques LESCOT wrote:
>>> HAPPY NEW YEAR !! :-)
>>>
>>> Philipp,
>>>
>>> I don't think this is necessary to open a new feature request, as
>>> while testing on my own, the Validation is correct ('-2' as a upper
>>> bound is valid, '-3' not).
>>> Since we have enabled validation on the Ecore Tools diagram, it uses
>>> the default EcoreValidator : GMF generated all the necessary stuff.
>>> We haven't forked the validation process to provide our own validator.
>>>
>>> Ed and others,
>>>
>>> I wonder how we could graphically represent the EReference
>>> multiplicity when the upper bound is '-2' ?
>>> For '-1' we display a star ('*') and for now, the same is used when
>>> upper bound is set as '-2'.
>>> In the Tree editor I noticed that the icon used when setting the
>>> upper bound as '-2' was the one showing 'n..m' : I wonder whether
>>> this is a bug or not ? Should we use a similar thing ?
>>>
>>> Regards,
>>> Jacques
>>>
>>> Philipp W. Kutter a écrit :
>>>> Ecore Tools people: shall I open the feature request?
>>>>
>>>> Best, Philipp
>>>>
>>>> Philipp W. Kutter wrote:
>>>>> Ed, I added your comment to the corresponding feature request.
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>>
>>>>> The Ecore Tools peopls may want to create one for "reusing
>>>>> EcoreValidator" and mark mine as duplicate.
>>>>>
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Lucas,
>>>>>>
>>>>>> I guess I should really have a look at how the validation
>>>>>> provided there is different from what's provided directly by
>>>>>> EcoreValidator itself. I'm more than happy to look at adding
>>>>>> anything missing from EcoreValidator so it could be reused
>>>>>> directly. (There are quite a few tricky constraints with respect
>>>>>> to the generics.)
>>>>>>
>>>>>>
>>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [Ecore Tools] Upper Bound = -2 [message #613064 is a reply to message #105673] Wed, 02 January 2008 15:52 Go to previous message
Jacques LESCOT is currently offline Jacques LESCOTFriend
Messages: 247
Registered: July 2009
Senior Member
Done.

Link to the enhancement request :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214120

Ed Merks a écrit :
> Jacques,
>
> Please open an enhancement request and we'll use it to to prompt us to
> get the graphic designers to create a new icon for us.
>
>
> Jacques LESCOT wrote:
>> I was also thinking to display '?' when the feature is set as '-2'.
>>
>> Ed Merks a écrit :
>>> Jacques,
>>>
>>> I'm not sure that n..m is the best thing to display either; we do
>>> that whenever the upper bound isn't 1 or -1 or the lower bound isn't
>>> 0 or 1, i.e., when none of the other simpler (more usual) icons
>>> apply. Technically the -2 indicates unspecified as defined by this
>>> ETypedElement constant:
>>>
>>> /**
>>> * A value indicating that there is an unspecified {@link
>>> #getUpperBound upper bound}.
>>> * @see #getUpperBound()
>>> */
>>> int UNSPECIFIED_MULTIPLICITY = -2;
>>>
>>> So perhaps something like 0..? would be more appropriate. The
>>> existing icons predated the use of -2. Then again, n..m does seem
>>> reasonable though it doesn't make the fact that m is the special
>>> value -2 at all clear. Any suggestions for improvements are more
>>> than welcome! I'm more than happy to agree on something better and
>>> make corresponding changes in Sample Ecore Editor...
>>>
>>>
>>> Jacques LESCOT wrote:
>>>> HAPPY NEW YEAR !! :-)
>>>>
>>>> Philipp,
>>>>
>>>> I don't think this is necessary to open a new feature request, as
>>>> while testing on my own, the Validation is correct ('-2' as a upper
>>>> bound is valid, '-3' not).
>>>> Since we have enabled validation on the Ecore Tools diagram, it uses
>>>> the default EcoreValidator : GMF generated all the necessary stuff.
>>>> We haven't forked the validation process to provide our own validator.
>>>>
>>>> Ed and others,
>>>>
>>>> I wonder how we could graphically represent the EReference
>>>> multiplicity when the upper bound is '-2' ?
>>>> For '-1' we display a star ('*') and for now, the same is used when
>>>> upper bound is set as '-2'.
>>>> In the Tree editor I noticed that the icon used when setting the
>>>> upper bound as '-2' was the one showing 'n..m' : I wonder whether
>>>> this is a bug or not ? Should we use a similar thing ?
>>>>
>>>> Regards,
>>>> Jacques
>>>>
>>>> Philipp W. Kutter a écrit :
>>>>> Ecore Tools people: shall I open the feature request?
>>>>>
>>>>> Best, Philipp
>>>>>
>>>>> Philipp W. Kutter wrote:
>>>>>> Ed, I added your comment to the corresponding feature request.
>>>>>>
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213785
>>>>>>
>>>>>> The Ecore Tools peopls may want to create one for "reusing
>>>>>> EcoreValidator" and mark mine as duplicate.
>>>>>>
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Lucas,
>>>>>>>
>>>>>>> I guess I should really have a look at how the validation
>>>>>>> provided there is different from what's provided directly by
>>>>>>> EcoreValidator itself. I'm more than happy to look at adding
>>>>>>> anything missing from EcoreValidator so it could be reused
>>>>>>> directly. (There are quite a few tricky constraints with respect
>>>>>>> to the generics.)
>>>>>>>
>>>>>>>
>>>
Previous Topic:[CDO] Connection failures
Next Topic:[Ecore Tools] How to make lines show up for super types and references?
Goto Forum:
  


Current Time: Sat Sep 19 17:02:09 GMT 2020

Powered by FUDForum. Page generated in 0.02415 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top