Home » Modeling » EMF » Missing Model Object in the Example EMF Model Creation Wizard
| | |
| Re: Missing Model Object in the Example EMF Model Creation Wizard [message #408967 is a reply to message #408962] |
Wed, 02 May 2007 21:36   |
 Matthew Rawlings
Messages: 39
Registered: July 2009 |
Member |
|
|
This is the correct schema to reproduce the problem. Apologies for
publishing the incorrect schema before.
When I use this schema I get an empty drop down box when selecting a Model
Object in the creation wizard.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FpML" type="Document">
<xs:annotation>
<xs:documentation xml:lang="en">The FpML element forms the root for any
conforming FpML instance document. The actual structure of the document is
determined by setting the 'type' attribute to an appropriate derived subtype
of the complex type Document.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="Document" abstract="true">
<xs:annotation>
<xs:documentation xml:lang="en">The abstract base type from which all
FpML compliant messages and documents must be derived.</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref="StandardAttributes.atts"/>
</xs:complexType>
<xs:attributeGroup name="StandardAttributes.atts">
<xs:attribute name="version" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">Indicate which version of the FpML
Schema an FpML message adheres to.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="4-0"/>
<xs:enumeration value="4-1"/>
<xs:enumeration value="4-2"/>
<xs:enumeration value="4-3"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="expectedBuild" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation xml:lang="en">The message creator can send the build
number of the schema on which they built the messages against.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="actualBuild" type="xs:positiveInteger" fixed="3">
<xs:annotation>
<xs:documentation xml:lang="en">Taken from the schemas that the
recipient validated against. Every time there is a change on the schema,
validation rules, or examples within a version the actual build number is
incremented. If no changes have been made between releases within a version
(i.e. from Trial Recommendation to Recommendation) the actual build number
stays the same.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:attributeGroup>
<xs:complexType name="DataDocument">
<xs:annotation>
<xs:documentation xml:lang="en">A type defining a content model that is
backwards compatible with older FpML releases and which can be used to
contain sets of data without expressing any processing
intention.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="Document">
<xs:sequence>
<xs:group ref="Validation.model"/>
<xs:element name="party" type="xs:string" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation xml:lang="en">A legal entity or a subdivision of a
legal entity.</xs:documentation>
<xs:documentation xml:lang="en">Parties can perform multiple roles in
a trade lifecycle. For example, the principal parties obligated to make
payments from time to time during the term of the trade, but may include
other parties involved in, or incidental to, the trade, such as parties
acting in the role of novation transferor/transferee, broker, calculation
agent, etc. In FpML roles are defined in multiple places within a
document.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="Validation.model">
<xs:sequence>
<xs:element name="validation" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
</xs:schema>
|
|
|
| Re: Missing Model Object in the Example EMF Model Creation Wizard [message #408969 is a reply to message #408967] |
Wed, 02 May 2007 21:56 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Matthew,
Since Document is abstract the generated code I showed in the previous
post won't and can't create an instance of it and it's not smart enough
to look for derived classes that could substitute. It's a very odd
design for a schema to define a model for which an xsi:type is needed
for the root element. I've never seen one like that before...
Matthew Rawlings wrote:
> This is the correct schema to reproduce the problem. Apologies for
> publishing the incorrect schema before.
>
> When I use this schema I get an empty drop down box when selecting a Model
> Object in the creation wizard.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
> <xs:element name="FpML" type="Document">
> <xs:annotation>
> <xs:documentation xml:lang="en">The FpML element forms the root for any
> conforming FpML instance document. The actual structure of the document is
> determined by setting the 'type' attribute to an appropriate derived subtype
> of the complex type Document.</xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:complexType name="Document" abstract="true">
> <xs:annotation>
> <xs:documentation xml:lang="en">The abstract base type from which all
> FpML compliant messages and documents must be derived.</xs:documentation>
> </xs:annotation>
> <xs:attributeGroup ref="StandardAttributes.atts"/>
> </xs:complexType>
> <xs:attributeGroup name="StandardAttributes.atts">
> <xs:attribute name="version" use="required">
> <xs:annotation>
> <xs:documentation xml:lang="en">Indicate which version of the FpML
> Schema an FpML message adheres to.</xs:documentation>
> </xs:annotation>
> <xs:simpleType>
> <xs:restriction base="xs:token">
> <xs:enumeration value="4-0"/>
> <xs:enumeration value="4-1"/>
> <xs:enumeration value="4-2"/>
> <xs:enumeration value="4-3"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:attribute>
> <xs:attribute name="expectedBuild" type="xs:positiveInteger">
> <xs:annotation>
> <xs:documentation xml:lang="en">The message creator can send the build
> number of the schema on which they built the messages against.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> <xs:attribute name="actualBuild" type="xs:positiveInteger" fixed="3">
> <xs:annotation>
> <xs:documentation xml:lang="en">Taken from the schemas that the
> recipient validated against. Every time there is a change on the schema,
> validation rules, or examples within a version the actual build number is
> incremented. If no changes have been made between releases within a version
> (i.e. from Trial Recommendation to Recommendation) the actual build number
> stays the same.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:attributeGroup>
> <xs:complexType name="DataDocument">
> <xs:annotation>
> <xs:documentation xml:lang="en">A type defining a content model that is
> backwards compatible with older FpML releases and which can be used to
> contain sets of data without expressing any processing
> intention.</xs:documentation>
> </xs:annotation>
> <xs:complexContent>
> <xs:extension base="Document">
> <xs:sequence>
> <xs:group ref="Validation.model"/>
> <xs:element name="party" type="xs:string" minOccurs="0"
> maxOccurs="unbounded">
> <xs:annotation>
> <xs:documentation xml:lang="en">A legal entity or a subdivision of a
> legal entity.</xs:documentation>
> <xs:documentation xml:lang="en">Parties can perform multiple roles in
> a trade lifecycle. For example, the principal parties obligated to make
> payments from time to time during the term of the trade, but may include
> other parties involved in, or incidental to, the trade, such as parties
> acting in the role of novation transferor/transferee, broker, calculation
> agent, etc. In FpML roles are defined in multiple places within a
> document.</xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> <xs:group name="Validation.model">
> <xs:sequence>
> <xs:element name="validation" type="xs:string" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
> </xs:schema>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Missing Model Object in the Example EMF Model Creation Wizard [message #408974 is a reply to message #408972] |
Thu, 03 May 2007 11:12 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Matthew,
It being a standard doesn't mean it's a good design. ;-) In general,
hand modifying the wizard to provide only the useful/sensible choices
would seem like a reasonable way to deal with corner cases. So while a
feature request is reasonable, our limited development resource likely
needs to focus on more common issues, so without a contribution, it's
not a given that this will be addressed in the current release cycle.
Matthew Rawlings wrote:
> Ed,
>
> The example is from the FpML schema http://www.fpml.org/ which is a
> Standard for financial products used by Banks, Securities Houses,
> Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
> adopted in the financial services industry.
>
> As this is legal XML Schema shall I raise an unplanned enhancement for
> EMF to look for valid alternative types?
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Missing Model Object in the Example EMF Model Creation Wizard [message #409377 is a reply to message #408974] |
Fri, 18 May 2007 03:41 |
Eclipse User |
|
|
|
Originally posted by: treilly.prolifics.com
My 2 cents: I wouldn't categorize this as a corner case.
e.g.:
http://maven.apache.org/maven-v4_0_0.xsd
I would say separating types and elements is a best practice and allows for
better extensibility (even at the root element.)
Definitely strikes the "bug" note for me.
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:f1cg32$hq0$1@build.eclipse.org...
> Matthew,
>
> It being a standard doesn't mean it's a good design. ;-) In general,
> hand modifying the wizard to provide only the useful/sensible choices
> would seem like a reasonable way to deal with corner cases. So while a
> feature request is reasonable, our limited development resource likely
> needs to focus on more common issues, so without a contribution, it's not
> a given that this will be addressed in the current release cycle.
>
>
> Matthew Rawlings wrote:
>> Ed,
>>
>> The example is from the FpML schema http://www.fpml.org/ which is a
>> Standard for financial products used by Banks, Securities Houses,
>> Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
>> adopted in the financial services industry.
>>
>> As this is legal XML Schema shall I raise an unplanned enhancement for
>> EMF to look for valid alternative types?
>>
>>
|
|
|
| Re: Missing Model Object in the Example EMF Model Creation Wizard [message #409379 is a reply to message #409377] |
Fri, 18 May 2007 05:23 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030302020407050404040808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Tim,
I think you've misunderstood because the example you point at has a root
element for which the type is a non-abstract complex type, so it's
definitely not an example of a corner case schema in which there is not
even a single root element that can be used without also requiring an
xsi:type. So I'll continue to assert that such a situation is very odd
(I've only seen it once it all my years of looking at schemas) and it
doesn't strike me as a good thing.
Tim Reilly wrote:
> My 2 cents: I wouldn't categorize this as a corner case.
> e.g.:
> http://maven.apache.org/maven-v4_0_0.xsd
>
> I would say separating types and elements is a best practice and allows for
> better extensibility (even at the root element.)
> Definitely strikes the "bug" note for me.
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:f1cg32$hq0$1@build.eclipse.org...
>
>> Matthew,
>>
>> It being a standard doesn't mean it's a good design. ;-) In general,
>> hand modifying the wizard to provide only the useful/sensible choices
>> would seem like a reasonable way to deal with corner cases. So while a
>> feature request is reasonable, our limited development resource likely
>> needs to focus on more common issues, so without a contribution, it's not
>> a given that this will be addressed in the current release cycle.
>>
>>
>> Matthew Rawlings wrote:
>>
>>> Ed,
>>>
>>> The example is from the FpML schema http://www.fpml.org/ which is a
>>> Standard for financial products used by Banks, Securities Houses,
>>> Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
>>> adopted in the financial services industry.
>>>
>>> As this is legal XML Schema shall I raise an unplanned enhancement for
>>> EMF to look for valid alternative types?
>>>
>>>
>>>
>
>
>
--------------030302020407050404040808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tim,<br>
<br>
I think you've misunderstood because the example you point at has a
root element for which the type is a non-abstract complex type, so it's
definitely not an example of a corner case schema in which there is not
even a single root element that can be used without also requiring an
xsi:type. So I'll continue to assert that such a situation is very odd
(I've only seen it once it all my years of looking at schemas) and it
doesn't strike me as a good thing.<br>
<br>
<br>
Tim Reilly wrote:
<blockquote cite="midf2j78p$pk6$1@build.eclipse.org" type="cite">
<pre wrap="">My 2 cents: I wouldn't categorize this as a corner case.
e.g.:
<a class="moz-txt-link-freetext" href="http://maven.apache.org/maven-v4_0_0.xsd">http://maven.apache.org/maven-v4_0_0.xsd</a>
I would say separating types and elements is a best practice and allows for
better extensibility (even at the root element.)
Definitely strikes the "bug" note for me.
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:f1cg32$hq0$1@build.eclipse.org">news:f1cg32$hq0$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Matthew,
It being a standard doesn't mean it's a good design. ;-) In general,
hand modifying the wizard to provide only the useful/sensible choices
would seem like a reasonable way to deal with corner cases. So while a
feature request is reasonable, our limited development resource likely
needs to focus on more common issues, so without a contribution, it's not
a given that this will be addressed in the current release cycle.
Matthew Rawlings wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed,
The example is from the FpML schema <a class="moz-txt-link-freetext" href="http://www.fpml.org/">http://www.fpml.org/</a> which is a
Standard for financial products used by Banks, Securities Houses,
Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
adopted in the financial services industry.
As this is legal XML Schema shall I raise an unplanned enhancement for
EMF to look for valid alternative types?
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------030302020407050404040808--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| BUG 185357, Re: Missing Model Object in the Example EMF Model Creation Wizard [message #427143 is a reply to message #409379] |
Tue, 03 February 2009 21:02 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Dear Ed.
This was reported as Bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357
back in 2007.
We moved now forward 2 years, and I think that we should reconsider
things, that where corner-cases back then.
As well, consider that while what you say about XML Schema design may
be true, the problem could as well be looked at from the MOF/ECore
perspective:
Is having a main package, which has abstract classes, and then different
packages which implement the concrete classes such a corner case?
And how would we generate an editor for this case?
Please remember, that a very related problem, generating "create new"
actions in the editor for inheriting classes (not know in the package of
the class which has the corresponding feature) has been fixed by your team!
Please give me a little sign that you might reconsider your opinion, and
I'll put efforts in providing examples and in documenting variants of
this problem in the bug.
Best Regards, Philipp
Ed Merks wrote:
> Tim,
>
> I think you've misunderstood because the example you point at has a root
> element for which the type is a non-abstract complex type, so it's
> definitely not an example of a corner case schema in which there is not
> even a single root element that can be used without also requiring an
> xsi:type. So I'll continue to assert that such a situation is very odd
> (I've only seen it once it all my years of looking at schemas) and it
> doesn't strike me as a good thing.
>
>
> Tim Reilly wrote:
>> My 2 cents: I wouldn't categorize this as a corner case.
>> e.g.:
>> http://maven.apache.org/maven-v4_0_0.xsd
>>
>> I would say separating types and elements is a best practice and allows for
>> better extensibility (even at the root element.)
>> Definitely strikes the "bug" note for me.
>>
>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>> news:f1cg32$hq0$1@build.eclipse.org...
>>
>>> Matthew,
>>>
>>> It being a standard doesn't mean it's a good design. ;-) In general,
>>> hand modifying the wizard to provide only the useful/sensible choices
>>> would seem like a reasonable way to deal with corner cases. So while a
>>> feature request is reasonable, our limited development resource likely
>>> needs to focus on more common issues, so without a contribution, it's not
>>> a given that this will be addressed in the current release cycle.
>>>
>>>
>>> Matthew Rawlings wrote:
>>>
>>>> Ed,
>>>>
>>>> The example is from the FpML schema http://www.fpml.org/ which is a
>>>> Standard for financial products used by Banks, Securities Houses,
>>>> Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
>>>> adopted in the financial services industry.
>>>>
>>>> As this is legal XML Schema shall I raise an unplanned enhancement for
>>>> EMF to look for valid alternative types?
>>>>
>>>>
>>>>
>>
>>
>>
>
|
|
|
| Re: BUG 185357, Re: Missing Model Object in the Example EMF Model Creation Wizard [message #427148 is a reply to message #427143] |
Wed, 04 February 2009 12:14 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040309060800060709080203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Philipp,
Comments below.
Philipp Kutter wrote:
> Dear Ed.
> This was reported as Bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357
> back in 2007.
>
> We moved now forward 2 years, and I think that we should reconsider
> things, that where corner-cases back then.
I've got a list of 100 bugzillas all of which are worth (re)considering:
https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced
< https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced>
The vast majority of these have no associated patches and are
effectively waiting for me to do the work.
>
> As well, consider that while what you say about XML Schema design may
> be true, the problem could as well be looked at from the MOF/ECore
> perspective:
> Is having a main package, which has abstract classes, and then
> different packages which implement the concrete classes such a
> corner case?
Yes, I think so.
>
> And how would we generate an editor for this case?
Given that you only have abstract classes, there's really nothing to
create so while we can have an editor, and we support extensible child
creation, we can't really generate a wizard that creates anything since
as you've described, there is nothing to create.
>
> Please remember, that a very related problem, generating "create new"
> actions in the editor for inheriting classes (not know in the package
> of the class which has the corresponding feature) has been fixed by
> your team!
There are few things I forget. :-P
>
> Please give me a little sign that you might reconsider your opinion, and
> I'll put efforts in providing examples and in documenting variants of
> this problem in the bug.
It's just not a high priority for me. Given that I have 100 things to
do, I will need to spend my time on the things that personally feel are
likely to have the most value for the most people. This problem just
isn't high on that list. What's at the top of my list right now is
access listeners https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
and even finding time for that is far too challenging.
>
> Best Regards, Philipp
>
> Ed Merks wrote:
>> Tim,
>>
>> I think you've misunderstood because the example you point at has a
>> root element for which the type is a non-abstract complex type, so
>> it's definitely not an example of a corner case schema in which there
>> is not even a single root element that can be used without also
>> requiring an xsi:type. So I'll continue to assert that such a
>> situation is very odd (I've only seen it once it all my years of
>> looking at schemas) and it doesn't strike me as a good thing.
>>
>>
>> Tim Reilly wrote:
>>> My 2 cents: I wouldn't categorize this as a corner case.
>>> e.g.:
>>> http://maven.apache.org/maven-v4_0_0.xsd
>>>
>>> I would say separating types and elements is a best practice and
>>> allows for better extensibility (even at the root element.)
>>> Definitely strikes the "bug" note for me.
>>>
>>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>>> news:f1cg32$hq0$1@build.eclipse.org...
>>>
>>>> Matthew,
>>>>
>>>> It being a standard doesn't mean it's a good design. ;-) In
>>>> general, hand modifying the wizard to provide only the
>>>> useful/sensible choices would seem like a reasonable way to deal
>>>> with corner cases. So while a feature request is reasonable, our
>>>> limited development resource likely needs to focus on more common
>>>> issues, so without a contribution, it's not a given that this will
>>>> be addressed in the current release cycle.
>>>>
>>>>
>>>> Matthew Rawlings wrote:
>>>>
>>>>> Ed,
>>>>>
>>>>> The example is from the FpML schema http://www.fpml.org/ which is
>>>>> a Standard for financial products used by Banks, Securities
>>>>> Houses, Brokerages, Insurers, Hedge Funds, and Exchanges. It is
>>>>> very widely adopted in the financial services industry.
>>>>>
>>>>> As this is legal XML Schema shall I raise an unplanned enhancement
>>>>> for EMF to look for valid alternative types?
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
--------------040309060800060709080203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Philipp,<br>
<br>
Comments below.<br>
<br>
Philipp Kutter wrote:
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite">Dear
Ed.
<br>
This was reported as Bug
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357">https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357</a>
<br>
back in 2007.
<br>
<br>
We moved now forward 2 years, and I think that we should reconsider
things, that where corner-cases back then.
<br>
</blockquote>
I've got a list of 100 bugzillas all of which are worth (re)considering:<br>
<blockquote><a
href=" https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&am p ;component=Core&component=Doc&component=Edit &component=Mapping&component=Tools&c omponent=XML/XMI&bug_status=NEW&bug_status=A SSIGNED&bug_status=REOPENED&bug_status=RESOL VED&resolution=FIXED&resolution=---& order=bugs.bug_status,bugs.target_milestone,bugs.bug_id& amp;query_format=advanced "> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&am p ;component=Core&component=Doc&component=Edit &component=Mapping&component=Tools&c omponent=XML/XMI&bug_status=NEW&bug_status=A SSIGNED&bug_status=REOPENED&bug_status=RESOL VED&resolution=FIXED&resolution=---& order=bugs.bug_status,bugs.target_milestone,bugs.bug_id& amp;query_format=advanced </a><br>
</blockquote>
The vast majority of these have no associated patches and are
effectively waiting for me to do the work.<br>
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite"><br>
As well, consider that while what you say about XML Schema design may
<br>
be true, the problem could as well be looked at from the MOF/ECore
perspective:
<br>
Is having a main package, which has abstract classes, and then
different packages which implement the concrete classes such a
corner case?
<br>
</blockquote>
Yes, I think so.<br>
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite"><br>
And how would we generate an editor for this case?
<br>
</blockquote>
Given that you only have abstract classes, there's really nothing to
create so while we can have an editor, and we support extensible child
creation, we can't really generate a wizard that creates anything since
as you've described, there is nothing to create.<br>
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite"><br>
Please remember, that a very related problem, generating "create new"
actions in the editor for inheriting classes (not know in the package
of the class which has the corresponding feature) has been fixed by
your team!
<br>
</blockquote>
There are few things I forget. :-P<br>
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite"><br>
Please give me a little sign that you might reconsider your opinion,
and
<br>
I'll put efforts in providing examples and in documenting variants of
this problem in the bug.
<br>
</blockquote>
It's just not a high priority for me. Given that I have 100 things to
do, I will need to spend my time on the things that personally feel are
likely to have the most value for the most people. This problem just
isn't high on that list. What's at the top of my list right now is
access listeners <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130">https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130</a>
and even finding time for that is far too challenging.<br>
<blockquote cite="mid:4988B0E6.6000800@montages.com" type="cite"><br>
Best Regards, Philipp
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Tim,
<br>
<br>
I think you've misunderstood because the example you point at has a
root element for which the type is a non-abstract complex type, so it's
definitely not an example of a corner case schema in which there is not
even a single root element that can be used without also requiring an
xsi:type. So I'll continue to assert that such a situation is very odd
(I've only seen it once it all my years of looking at schemas) and it
doesn't strike me as a good thing.
<br>
<br>
<br>
Tim Reilly wrote:
<br>
<blockquote type="cite">My 2 cents: I wouldn't categorize this as a
corner case.
<br>
e.g.:
<br>
<a class="moz-txt-link-freetext" href="http://maven.apache.org/maven-v4_0_0.xsd">http://maven.apache.org/maven-v4_0_0.xsd</a>
<br>
<br>
I would say separating types and elements is a best practice and allows
for better extensibility (even at the root element.)
<br>
Definitely strikes the "bug" note for me.
<br>
<br>
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:f1cg32$hq0$1@build.eclipse.org">news:f1cg32$hq0$1@build.eclipse.org</a>...
<br>
<blockquote type="cite">Matthew,
<br>
<br>
It being a standard doesn't mean it's a good design. ;-) In general,
hand modifying the wizard to provide only the useful/sensible choices
would seem like a reasonable way to deal with corner cases. So while a
feature request is reasonable, our limited development resource likely
needs to focus on more common issues, so without a contribution, it's
not a given that this will be addressed in the current release cycle.
<br>
<br>
<br>
Matthew Rawlings wrote:
<br>
<blockquote type="cite">Ed,
<br>
<br>
The example is from the FpML schema <a class="moz-txt-link-freetext" href="http://www.fpml.org/">http://www.fpml.org/</a> which is a
Standard for financial products used by Banks, Securities Houses,
Brokerages, Insurers, Hedge Funds, and Exchanges. It is very widely
adopted in the financial services industry.
<br>
<br>
As this is legal XML Schema shall I raise an unplanned enhancement for
EMF to look for valid alternative types?
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------040309060800060709080203--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: BUG 185357, Re: Missing Model Object in the Example EMF Model Creation Wizard [message #427221 is a reply to message #427148] |
Fri, 06 February 2009 15:31 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Ed.
I understand. What we'll do is creating some proposal and associated
patches what to do, which relate to both the Editor root element and
extensible child creation.
What I have in mind is an extension point, where other ECore models can
be entered, which will be used when the classes for "extensible child
creation" or the "root elements" are proposed.
Are there other proposals or ideas in bugzillas I have to coordinate
with for this?
Best Regards,
Philipp
PS: In our OCL usage, we will correspondingly add OCL expressions to
constraint and construct the proposed classes both for extensible child
creation (OCL constraints added to the corresponding containment
feature) and editor root elements (OCL constraints added to the package
which is used as basis for the editor.
Marc: can you please create a corresponding feature request in our
internal bugzilla which includes contribution to Bug 185357
Ed Merks wrote:
> Philipp,
>
> Comments below.
>
> Philipp Kutter wrote:
>> Dear Ed.
>> This was reported as Bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357
>> back in 2007.
>>
>> We moved now forward 2 years, and I think that we should reconsider
>> things, that where corner-cases back then.
> I've got a list of 100 bugzillas all of which are worth (re)considering:
>
> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced
> < https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced>
>
> The vast majority of these have no associated patches and are
> effectively waiting for me to do the work.
>>
>> As well, consider that while what you say about XML Schema design may
>> be true, the problem could as well be looked at from the MOF/ECore
>> perspective:
>> Is having a main package, which has abstract classes, and then
>> different packages which implement the concrete classes such a
>> corner case?
> Yes, I think so.
>>
>> And how would we generate an editor for this case?
> Given that you only have abstract classes, there's really nothing to
> create so while we can have an editor, and we support extensible child
> creation, we can't really generate a wizard that creates anything since
> as you've described, there is nothing to create.
>>
>> Please remember, that a very related problem, generating "create new"
>> actions in the editor for inheriting classes (not know in the package
>> of the class which has the corresponding feature) has been fixed by
>> your team!
> There are few things I forget. :-P
>>
>> Please give me a little sign that you might reconsider your opinion, and
>> I'll put efforts in providing examples and in documenting variants of
>> this problem in the bug.
> It's just not a high priority for me. Given that I have 100 things to
> do, I will need to spend my time on the things that personally feel are
> likely to have the most value for the most people. This problem just
> isn't high on that list. What's at the top of my list right now is
> access listeners https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130
> and even finding time for that is far too challenging.
>>
>> Best Regards, Philipp
>>
>> Ed Merks wrote:
>>> Tim,
>>>
>>> I think you've misunderstood because the example you point at has a
>>> root element for which the type is a non-abstract complex type, so
>>> it's definitely not an example of a corner case schema in which there
>>> is not even a single root element that can be used without also
>>> requiring an xsi:type. So I'll continue to assert that such a
>>> situation is very odd (I've only seen it once it all my years of
>>> looking at schemas) and it doesn't strike me as a good thing.
>>>
>>>
>>> Tim Reilly wrote:
>>>> My 2 cents: I wouldn't categorize this as a corner case.
>>>> e.g.:
>>>> http://maven.apache.org/maven-v4_0_0.xsd
>>>>
>>>> I would say separating types and elements is a best practice and
>>>> allows for better extensibility (even at the root element.)
>>>> Definitely strikes the "bug" note for me.
>>>>
>>>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>>>> news:f1cg32$hq0$1@build.eclipse.org...
>>>>
>>>>> Matthew,
>>>>>
>>>>> It being a standard doesn't mean it's a good design. ;-) In
>>>>> general, hand modifying the wizard to provide only the
>>>>> useful/sensible choices would seem like a reasonable way to deal
>>>>> with corner cases. So while a feature request is reasonable, our
>>>>> limited development resource likely needs to focus on more common
>>>>> issues, so without a contribution, it's not a given that this will
>>>>> be addressed in the current release cycle.
>>>>>
>>>>>
>>>>> Matthew Rawlings wrote:
>>>>>
>>>>>> Ed,
>>>>>>
>>>>>> The example is from the FpML schema http://www.fpml.org/ which is
>>>>>> a Standard for financial products used by Banks, Securities
>>>>>> Houses, Brokerages, Insurers, Hedge Funds, and Exchanges. It is
>>>>>> very widely adopted in the financial services industry.
>>>>>>
>>>>>> As this is legal XML Schema shall I raise an unplanned enhancement
>>>>>> for EMF to look for valid alternative types?
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
|
|
|
| Re: BUG 185357, Re: Missing Model Object in the Example EMF Model Creation Wizard [message #427224 is a reply to message #427221] |
Fri, 06 February 2009 18:09 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Philipp,
Certainly bugzillas with patches move up in my priority queue. Helping
those who help themselves tends to pay off better and demonstrates that
the problem truly is important enough to invest the time. Discussions
in the bugzilla are a good place to make progress.
Philipp Kutter wrote:
> Hi, Ed.
> I understand. What we'll do is creating some proposal and associated
> patches what to do, which relate to both the Editor root element and
> extensible child creation.
>
> What I have in mind is an extension point, where other ECore models
> can be entered, which will be used when the classes for "extensible
> child creation" or the "root elements" are proposed.
>
> Are there other proposals or ideas in bugzillas I have to coordinate
> with for this?
>
> Best Regards,
> Philipp
>
> PS: In our OCL usage, we will correspondingly add OCL expressions to
> constraint and construct the proposed classes both for extensible
> child creation (OCL constraints added to the corresponding containment
> feature) and editor root elements (OCL constraints added to the
> package which is used as basis for the editor.
>
> Marc: can you please create a corresponding feature request in our
> internal bugzilla which includes contribution to Bug 185357
>
> Ed Merks wrote:
>> Philipp,
>>
>> Comments below.
>>
>> Philipp Kutter wrote:
>>> Dear Ed.
>>> This was reported as Bug
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=185357
>>> back in 2007.
>>>
>>> We moved now forward 2 years, and I think that we should reconsider
>>> things, that where corner-cases back then.
>> I've got a list of 100 bugzillas all of which are worth (re)considering:
>>
>>
>> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced
>>
>>
>> < https://bugs.eclipse.org/bugs/buglist.cgi?product=EMF&co mponent=Core&component=Doc&component=Edit&compon ent=Mapping&component=Tools&component=XML/XMI&bu g_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED &bug_status=RESOLVED&resolution=FIXED&resolution =---&order=bugs.bug_status,bugs.target_milestone,bugs.bu g_id&query_format=advanced>
>>
>>
>> The vast majority of these have no associated patches and are
>> effectively waiting for me to do the work.
>>>
>>> As well, consider that while what you say about XML Schema design may
>>> be true, the problem could as well be looked at from the MOF/ECore
>>> perspective:
>>> Is having a main package, which has abstract classes, and then
>>> different packages which implement the concrete classes such a
>>> corner case?
>> Yes, I think so.
>>>
>>> And how would we generate an editor for this case?
>> Given that you only have abstract classes, there's really nothing to
>> create so while we can have an editor, and we support extensible
>> child creation, we can't really generate a wizard that creates
>> anything since as you've described, there is nothing to create.
>>>
>>> Please remember, that a very related problem, generating "create
>>> new" actions in the editor for inheriting classes (not know in the
>>> package of the class which has the corresponding feature) has been
>>> fixed by your team!
>> There are few things I forget. :-P
>>>
>>> Please give me a little sign that you might reconsider your opinion,
>>> and
>>> I'll put efforts in providing examples and in documenting variants
>>> of this problem in the bug.
>> It's just not a high priority for me. Given that I have 100 things
>> to do, I will need to spend my time on the things that personally
>> feel are likely to have the most value for the most people. This
>> problem just isn't high on that list. What's at the top of my list
>> right now is access listeners
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130 and even finding
>> time for that is far too challenging.
>>>
>>> Best Regards, Philipp
>>>
>>> Ed Merks wrote:
>>>> Tim,
>>>>
>>>> I think you've misunderstood because the example you point at has a
>>>> root element for which the type is a non-abstract complex type, so
>>>> it's definitely not an example of a corner case schema in which
>>>> there is not even a single root element that can be used without
>>>> also requiring an xsi:type. So I'll continue to assert that such a
>>>> situation is very odd (I've only seen it once it all my years of
>>>> looking at schemas) and it doesn't strike me as a good thing.
>>>>
>>>>
>>>> Tim Reilly wrote:
>>>>> My 2 cents: I wouldn't categorize this as a corner case.
>>>>> e.g.:
>>>>> http://maven.apache.org/maven-v4_0_0.xsd
>>>>>
>>>>> I would say separating types and elements is a best practice and
>>>>> allows for better extensibility (even at the root element.)
>>>>> Definitely strikes the "bug" note for me.
>>>>>
>>>>> "Ed Merks" <merks@ca.ibm.com> wrote in message
>>>>> news:f1cg32$hq0$1@build.eclipse.org...
>>>>>
>>>>>> Matthew,
>>>>>>
>>>>>> It being a standard doesn't mean it's a good design. ;-) In
>>>>>> general, hand modifying the wizard to provide only the
>>>>>> useful/sensible choices would seem like a reasonable way to deal
>>>>>> with corner cases. So while a feature request is reasonable, our
>>>>>> limited development resource likely needs to focus on more common
>>>>>> issues, so without a contribution, it's not a given that this
>>>>>> will be addressed in the current release cycle.
>>>>>>
>>>>>>
>>>>>> Matthew Rawlings wrote:
>>>>>>
>>>>>>> Ed,
>>>>>>>
>>>>>>> The example is from the FpML schema http://www.fpml.org/ which
>>>>>>> is a Standard for financial products used by Banks, Securities
>>>>>>> Houses, Brokerages, Insurers, Hedge Funds, and Exchanges. It is
>>>>>>> very widely adopted in the financial services industry.
>>>>>>>
>>>>>>> As this is legal XML Schema shall I raise an unplanned
>>>>>>> enhancement for EMF to look for valid alternative types?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:27:20 GMT 2024
Powered by FUDForum. Page generated in 0.04149 seconds |
] 
Search
Help
Register
Login
Home
