Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Extension to XSD?
Extension to XSD? [message #68360] Wed, 14 June 2006 20:34 Go to next message
Eclipse User
Originally posted by: stockina.fmi.uni-passau.de

Hello,

I want to extend the XSD validator by a self-written feature. Basically
what I want to accomplish it to restrain a <xsd:any/> tag in a complex
type definition to only accept elements of types that extend a specific
base type (some sort of polymorphism if you want). so what I want to end
up with is something like <xsd:any typeRestriction="ns0:MyBaseType"/>.

I guess specifying this in a valid XSD document wouldn't be all that
hard - simply provide a namespace for the typeRestriction attribute and
things should go well, shouldn't they? my question is: how to integrate
that in a JAXB compliant XSD validator? Is there a easy way to do what I
want or do I need to implement my own XSD validator (which would indeed
be overkill).

Thanks for your help,

Alex
Re: Extension to XSD? [message #68370 is a reply to message #68360] Wed, 14 June 2006 21:45 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

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

Alex,

I can't answer questions about how to do things with JAXB because I
don't know how that works....

In EMF we do very similar things with annotations, e.g.,
ecore:reference, to map XML Schema to Ecore:

http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf

It's an interesting idea to try to constraint a wildcard in this way.
Have you considered just using substitution groups since they provide
the type constraint directly?


Alexander Stockinger wrote:
> Hello,
>
> I want to extend the XSD validator by a self-written feature.
> Basically what I want to accomplish it to restrain a <xsd:any/> tag in
> a complex type definition to only accept elements of types that extend
> a specific base type (some sort of polymorphism if you want). so what
> I want to end up with is something like <xsd:any
> typeRestriction="ns0:MyBaseType"/>.
>
> I guess specifying this in a valid XSD document wouldn't be all that
> hard - simply provide a namespace for the typeRestriction attribute
> and things should go well, shouldn't they? my question is: how to
> integrate that in a JAXB compliant XSD validator? Is there a easy way
> to do what I want or do I need to implement my own XSD validator
> (which would indeed be overkill).
>
> Thanks for your help,
>
> Alex


--------------020303040601090508070503
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
I can't answer questions about how to do things with JAXB because I
don't know how that works....<br>
<br>
In EMF we do very similar things with annotations, e.g.,
ecore:reference, to map XML Schema to Ecore:<br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf</a><br>
</blockquote>
It's an interesting idea to try to constraint a wildcard in this way.&nbsp;
Have you considered just using substitution groups since they provide
the type constraint directly?<br>
<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6prqc$2cj$1@utils.eclipse.org" type="cite">Hello,
<br>
<br>
I want to extend the XSD validator by a self-written feature. Basically
what I want to accomplish it to restrain a &lt;xsd:any/&gt; tag in a
complex type definition to only accept elements of types that extend a
specific base type (some sort of polymorphism if you want). so what I
want to end up with is something like &lt;xsd:any
typeRestriction="ns0:MyBaseType"/&gt;.
<br>
<br>
I guess specifying this in a valid XSD document wouldn't be all that
hard - simply provide a namespace for the typeRestriction attribute and
things should go well, shouldn't they? my question is: how to integrate
that in a JAXB compliant XSD validator? Is there a easy way to do what
I want or do I need to implement my own XSD validator (which would
indeed be overkill).
<br>
<br>
Thanks for your help,
<br>
<br>
Alex
<br>
</blockquote>
<br>
</body>
</html>

--------------020303040601090508070503--
Re: Extension to XSD? [message #68380 is a reply to message #68370] Thu, 15 June 2006 07:12 Go to previous messageGo to next message
Eclipse User
Originally posted by: stockina.fmi.uni-passau.de

Hello Ed,

>
> It's an interesting idea to try to constraint a wildcard in this way.
> Have you considered just using substitution groups since they provide
> the type constraint directly?
>
I read about substitution groups but basically what scared me away was
this sentence in the W3C XSD tutorial: "Note that all elements in the
substitutionGroup (the head element and the substitutable elements) must
be declared as global elements, otherwise it will not work!"

I want to use this for specifying a schema for SWT based dialog "style
sheets". So What I try is: Have the complexType "swtDialog" specify that
it only accepts elements of the abstract complex type "swtControl" but
without the need to specify each subtype of "swtControl" as an element
in "swtDialog".

With the requirement that elements in substitution groups must be global
I would allow dialog style-sheets that have a control as root element -
wouldn't I? That is surely not what I want to achieve.



Indeed I am playing around with something like EMF with the ability to
generate a model at runtime. The basic idea is to store the model
metadata in an XSD in memory and expose a DOM-implementation that offers
XML-style access to a model instance. That way you immediately get a
nice feature set virtually for free: XPath, XForms etc. I also allow
"reflection" of the DOM model by exposing the XSDTypeDefinition for a
Element via Node.getFeature().
The models can be specified using "ModelContributors". The only one I
implemented, yet, uses reflection at runtime on a java class hierarchy.
However one could also imagine using SQL, already existing XSD documents
or auto-generated code (where the advantage of auto-generated code
clearly is speed since it doesn't need to rely on reflection).

Back on topic. I just mention it because I think it's funny: You create
models from XSDs while my approach generates XSDs from models. The
original question is for a SWT based dialog front end that enables
editing the DOM structure of the model.

Thanks for you help,
Alex
Re: Extension to XSD? [message #68391 is a reply to message #68380] Thu, 15 June 2006 11:18 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

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

Alex,

Comments below.

Alexander Stockinger wrote:
> Hello Ed,
>
>>
>> It's an interesting idea to try to constraint a wildcard in this
>> way. Have you considered just using substitution groups since they
>> provide the type constraint directly?
>>
> I read about substitution groups but basically what scared me away was
> this sentence in the W3C XSD tutorial: "Note that all elements in the
> substitutionGroup (the head element and the substitutable elements)
> must be declared as global elements, otherwise it will not work!"
This is true, but wildcards only allow global elements as well, except
in some odd restriction scenarios.
> I want to use this for specifying a schema for SWT based dialog "style
> sheets". So What I try is: Have the complexType "swtDialog" specify
> that it only accepts elements of the abstract complex type
> "swtControl" but without the need to specify each subtype of
> "swtControl" as an element in "swtDialog".
Sounds like defining a substitution group element head of perhaps some
abstract base type swtControl. Any schema could then define an element
of a type derived from swtControl and use it in your swtDialog type.
>
> With the requirement that elements in substitution groups must be
> global I would allow dialog style-sheets that have a control as root
> element - wouldn't I? That is surely not what I want to achieve.
I'm not sure how you'll avoid the root element thing with your wildcard
approach.
>
>
>
> Indeed I am playing around with something like EMF with the ability to
> generate a model at runtime. The basic idea is to store the model
> metadata in an XSD in memory and expose a DOM-implementation that
> offers XML-style access to a model instance. That way you immediately
> get a nice feature set virtually for free: XPath, XForms etc. I also
> allow "reflection" of the DOM model by exposing the XSDTypeDefinition
> for a Element via Node.getFeature().
> The models can be specified using "ModelContributors". The only one I
> implemented, yet, uses reflection at runtime on a java class
> hierarchy. However one could also imagine using SQL, already existing
> XSD documents or auto-generated code (where the advantage of
> auto-generated code clearly is speed since it doesn't need to rely on
> reflection).
Yep. Sure sounds like EMF.
>
> Back on topic. I just mention it because I think it's funny: You
> create models from XSDs while my approach generates XSDs from models.
EMF does both. Given a model you can export it as a schema. So it's
possible to convert XSD to Ecore and to generate Java from that Ecore;
it's also possible to take advantage of @model annotations to go in the
reverse direction and generate Ecore from the Java, and generate a
schema from the Ecore. For many schemas, this XSD -> Ecore -> Java ->
Ecore -> XSD is effectively a round trip...
> The original question is for a SWT based dialog front end that enables
> editing the DOM structure of the model.
EMF also lets you save a resource as DOM and maintains a mapping between
the DOM and the model so that you can apply XPath to the DOM and map the
result of the valuation back onto the model.
>
> Thanks for you help,
> Alex
Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
< http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
to compare what you are trying to achieve with what's already
available? You might find that what you are trying to build could be
accomplished much more easily...

--------------040109040706070009010507
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Comments below.<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">Hello
Ed,
<br>
<br>
<blockquote type="cite"><br>
It's an interesting idea to try to constraint a wildcard in this way.&nbsp;
Have you considered just using substitution groups since they provide
the type constraint directly?
<br>
<br>
</blockquote>
I read about substitution groups but basically what scared me away was
this sentence in the W3C XSD tutorial: "Note that all elements in the
substitutionGroup (the head element and the substitutable elements)
must be declared as global elements, otherwise it will not work!"
<br>
</blockquote>
This is true, but wildcards only allow global elements as well, except
in some odd restriction scenarios.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">I want
to use this for specifying a schema for SWT based dialog "style
sheets". So What I try is: Have the complexType "swtDialog" specify
that it only accepts elements of the abstract complex type "swtControl"
but without the need to specify each subtype of "swtControl" as an
element in "swtDialog".
<br>
</blockquote>
Sounds like defining a substitution group element&nbsp; head of perhaps some
abstract base type swtControl.&nbsp;&nbsp; Any schema could then define an
element of a type derived from swtControl and use it in your swtDialog
type.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
With the requirement that elements in substitution groups must be
global I would allow dialog style-sheets that have a control as root
element - wouldn't I? That is surely not what I want to achieve.
<br>
</blockquote>
I'm not sure how you'll avoid the root element thing with your wildcard
approach.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
<br>
<br>
Indeed I am playing around with something like EMF with the ability to
generate a model at runtime. The basic idea is to store the model
metadata in an XSD in memory and expose a DOM-implementation that
offers &nbsp;XML-style access to a model instance. That way you immediately
get a nice feature set virtually for free: XPath, XForms etc. I also
allow "reflection" of the DOM model by exposing the XSDTypeDefinition
for a Element via Node.getFeature().
<br>
The models can be specified using "ModelContributors". The only one I
implemented, yet, uses reflection at runtime on a java class hierarchy.
However one could also imagine using SQL, already existing XSD
documents or auto-generated code (where the advantage of auto-generated
code clearly is speed since it doesn't need to rely on reflection).
<br>
</blockquote>
Yep.&nbsp; Sure sounds like EMF.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
Back on topic. I just mention it because I think it's funny: You create
models from XSDs while my approach generates XSDs from models. </blockquote>
EMF does both.&nbsp; Given a model you can export it as a schema.&nbsp; So it's
possible to convert XSD to Ecore and to generate Java from that Ecore;
it's also possible to take advantage of @model annotations to go in the
reverse direction and generate Ecore from the Java, and generate a
schema from the Ecore.&nbsp; For many schemas, this XSD -&gt; Ecore -&gt;
Java -&gt; Ecore -&gt; XSD is effectively a round trip...<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">The
original question is for a SWT based dialog front end that enables
editing the DOM structure of the model.
<br>
</blockquote>
EMF also lets you save a resource as DOM and maintains a mapping
between the DOM and the model so that you can apply XPath to the DOM
and map the result of the valuation back onto the model.&nbsp; <br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
Thanks for you help,
<br>
Alex
<br>
</blockquote>
Have you tried <a
href=" http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html">
Tutorial: Generating an EMF 2.1 Model using XML Schema</a> to compare
what you are trying to achieve with what's already available?&nbsp; You
might find that what you are trying to build could be accomplished much
more easily...<br>
</body>
</html>

--------------040109040706070009010507--
Re: Extension to XSD? [message #68399 is a reply to message #68391] Fri, 16 June 2006 06:27 Go to previous messageGo to next message
Eclipse User
Originally posted by: stockina.fmi.uni-passau.de

Hello Ed,

Comments below.

Ed Merks wrote:
>> I read about substitution groups but basically what scared me away was
>> this sentence in the W3C XSD tutorial: "Note that all elements in the
>> substitutionGroup (the head element and the substitutable elements)
>> must be declared as global elements, otherwise it will not work!"
>
> This is true, but wildcards only allow global elements as well, except
> in some odd restriction scenarios.
>
>> I want to use this for specifying a schema for SWT based dialog "style
>> sheets". So What I try is: Have the complexType "swtDialog" specify
>> that it only accepts elements of the abstract complex type
>> "swtControl" but without the need to specify each subtype of
>> "swtControl" as an element in "swtDialog".
>
> Sounds like defining a substitution group element head of perhaps some
> abstract base type swtControl. Any schema could then define an element
> of a type derived from swtControl and use it in your swtDialog type.
>
>>
>> With the requirement that elements in substitution groups must be
>> global I would allow dialog style-sheets that have a control as root
>> element - wouldn't I? That is surely not what I want to achieve.
>
> I'm not sure how you'll avoid the root element thing with your wildcard
> approach.
>
While the root element thing still bugs me it's probably the most
suitable way to go - at least it allows for validation of a dialog style
XML file.

> EMF also lets you save a resource as DOM and maintains a mapping between
> the DOM and the model so that you can apply XPath to the DOM and map the
> result of the valuation back onto the model.
>
That sounds _exactly_ like the thing I'm trying to accomplish.

>
> Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
> < http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
> to compare what you are trying to achieve with what's already
> available? You might find that what you are trying to build could be
> accomplished much more easily...

I already took a look at this tutorial, but everything about EMF I found
until now basically involved auto-generated code. This is not the
direction I want to go. I am more the "write clean model code and then
have a framework to do its best to create dialogs from it" - guy.

Indeed I am using a @Model annotation as well to mark getters/setters. I
also introduced a @Namespace tag for classes since I also allow for
other model contributors (say for SQL or XSD) that in rare cases might
produce naming conflicts.
I'm also using a @Restriction annotation on setters to define XSD-style
restrictions on the values of properties.

I think the main difference between the two approaches is that for EMF
you always need some kind of model description (XSD, Java interfaces,
UML etc.) to generate the model code while in my library you happily
write your java classes as normal (standard getter/setter conventions),
test them with JUnit or whatever you like and then you just throw the
finished classes along with some annotations into the pot - what you get
is a nice DOM structure with XSD-"reflection" and a toolkit of
dialog-classes that automagically offer editing facilities for the DOM
structure.

Probably I should really go ahead an use EMF for what I want to
accomplish but I'm more like "as little code as possible" (I always have
the concept of "less code - less bugs" in mind) and so EMF just involves
to much "redundant" specification for my taste. I do indeed like the
concept of EMF and I wish I heard earlier about it - would have saved me
a great deal of work. But right now I want to go a step further and have
the framework "interpret" the semantics of my class hierarchy.

I'm eager to hear your comments - maybe I just don't know enough about
EMF to see that it already offers what I want.

Thanks for your input,
Alex
Re: Extension to XSD? [message #68410 is a reply to message #68399] Fri, 16 June 2006 11:44 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

Alex,

Comments below.

Alexander Stockinger wrote:
> Hello Ed,
>
> Comments below.
>
> Ed Merks wrote:
>>> I read about substitution groups but basically what scared me away
>>> was this sentence in the W3C XSD tutorial: "Note that all elements
>>> in the substitutionGroup (the head element and the substitutable
>>> elements) must be declared as global elements, otherwise it will not
>>> work!"
>>
>> This is true, but wildcards only allow global elements as well,
>> except in some odd restriction scenarios.
>>
>>> I want to use this for specifying a schema for SWT based dialog
>>> "style sheets". So What I try is: Have the complexType "swtDialog"
>>> specify that it only accepts elements of the abstract complex type
>>> "swtControl" but without the need to specify each subtype of
>>> "swtControl" as an element in "swtDialog".
>>
>> Sounds like defining a substitution group element head of perhaps
>> some abstract base type swtControl. Any schema could then define an
>> element of a type derived from swtControl and use it in your
>> swtDialog type.
>>
>>>
>>> With the requirement that elements in substitution groups must be
>>> global I would allow dialog style-sheets that have a control as root
>>> element - wouldn't I? That is surely not what I want to achieve.
>>
>> I'm not sure how you'll avoid the root element thing with your
>> wildcard approach.
>>
> While the root element thing still bugs me it's probably the most
> suitable way to go - at least it allows for validation of a dialog
> style XML file.
>
>> EMF also lets you save a resource as DOM and maintains a mapping
>> between the DOM and the model so that you can apply XPath to the DOM
>> and map the result of the valuation back onto the model.
> That sounds _exactly_ like the thing I'm trying to accomplish.
In the org.eclipse.jet plugin (part of the EMFT project) there is even
an XPath evaluator than can evaluate XPath directly against your objects
without at DOM.
>
>>
>> Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
>> < http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
>> to compare what you are trying to achieve with what's already
>> available? You might find that what you are trying to build could be
>> accomplished much more easily...
>
> I already took a look at this tutorial, but everything about EMF I
> found until now basically involved auto-generated code. This is not
> the direction I want to go. I am more the "write clean model code and
> then have a framework to do its best to create dialogs from it" - guy.
This seems questionable. You must have a lot of time on your hands to
do so many things manually...
>
> Indeed I am using a @Model annotation as well to mark getters/setters.
> I also introduced a @Namespace tag for classes since I also allow for
> other model contributors (say for SQL or XSD) that in rare cases might
> produce naming conflicts.
> I'm also using a @Restriction annotation on setters to define
> XSD-style restrictions on the values of properties.
The joy of @annotations. I can imagine then day when there will be more
of these than anything else in the code. This seems not significantly
different from using EMF's @model annotations within the Javadoc.
>
> I think the main difference between the two approaches is that for EMF
> you always need some kind of model description (XSD, Java interfaces,
> UML etc.) to generate the model code while in my library you happily
> write your java classes as normal (standard getter/setter
> conventions), test them with JUnit or whatever you like and then you
> just throw the finished classes along with some annotations into the
> pot - what you get is a nice DOM structure with XSD-"reflection" and a
> toolkit of dialog-classes that automagically offer editing facilities
> for the DOM structure.
Your normal interfaces with getters and setters is a model definition.
EMF generates JUnit tests for you.
>
> Probably I should really go ahead an use EMF for what I want to
> accomplish but I'm more like "as little code as possible" (I always
> have the concept of "less code - less bugs" in mind) and so EMF just
> involves to much "redundant" specification for my taste. I do indeed
> like the concept of EMF and I wish I heard earlier about it - would
> have saved me a great deal of work. But right now I want to go a step
> further and have the framework "interpret" the semantics of my class
> hierarchy.
I'm more of the opinion that the more hand written code the more hand
written bugs you'll have. ;-)
>
> I'm eager to hear your comments - maybe I just don't know enough about
> EMF to see that it already offers what I want.
It pretty much sounds like everything you need is already there. Mostly
it seems your concern is that there is perhaps too much is already
there. I.e., what else would you need?
>
> Thanks for your input,
> Alex
Re: Extension to XSD? [message #68421 is a reply to message #68410] Fri, 16 June 2006 12:17 Go to previous messageGo to next message
Eclipse User
Originally posted by: stockina.fmi.uni-passau.de

Hi Ed,

comments see below :)

Ed Merks wrote:

> It pretty much sounds like everything you need is already there. Mostly
> it seems your concern is that there is perhaps too much is already
> there. I.e., what else would you need?

I indeed looks like this is the case. But maybe it's just me, but I
couldn't really find much more about EMF than "generate a fully blown
RCP application from various model definitions" - with lots of code
generated underway. This is definitely _not_ what I want.

While I see that automatic code generation has its advantages I worked
with some such components (like VE for example) and most of time they
make things worse instead of helping out - especially when things have
to be combined with user-written code - then back in the model
definition a change occurs so some code has to be generated again and
this time merged with the user-written parts - things like that.
I couldn't really find any documentation on how such situations would be
handled by EMF. If there is I'd love to hear about it - if not I'd be
happy if you could give me a hint where to find a book about EMF that is
worth its money.

To summarize my requirements:
1. generate a model from potentially already existing code
2. allow for restrictions specified in the model
3. offer convenient method of validating data against the model's
restrictions
4. on model change have "dependant" code (mostly dialogs and other user
input/output stuff) update (maybe even automatically during prototyping?)
5. not dependant on RCP (even if UI stuff has to be generated by the
framework)

My library currently does those things in the following way
1. reflection of java classes
2. annotations for the properties (at the setters)
3. using a validator class that validates against a XSDTypeDefinition
4. during prototyping dialogs are generated on the fly at runtime
5. dialogs are merely "XML Editors" so a implementation for virtually
any platform (SWT, Swing, XHTML/Ajax) is straight forward

Now if that is possible with EMF and you could point me to some good
documentation I'd be more than happy to give it a real shot.

Thanks for your help,

Alex
Re: Extension to XSD? [message #68432 is a reply to message #68421] Fri, 16 June 2006 12:49 Go to previous messageGo to next message
Eclipse User
Originally posted by: merks.ca.ibm.com

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

Alex,

Comments below...


Alexander Stockinger wrote:
> Hi Ed,
>
> comments see below :)
>
> Ed Merks wrote:
>
>> It pretty much sounds like everything you need is already there.
>> Mostly it seems your concern is that there is perhaps too much is
>> already there. I.e., what else would you need?
>
> I indeed looks like this is the case. But maybe it's just me, but I
> couldn't really find much more about EMF than "generate a fully blown
> RCP application from various model definitions" - with lots of code
> generated underway. This is definitely _not_ what I want.
If you put your rose colored glasses on, you can ignore anything you
don't want and see only what you do need, i.e., code that implements
your model.
>
> While I see that automatic code generation has its advantages I worked
> with some such components (like VE for example) and most of time they
> make things worse instead of helping out - especially when things have
> to be combined with user-written code - then back in the model
> definition a change occurs so some code has to be generated again and
> this time merged with the user-written parts - things like that.
> I couldn't really find any documentation on how such situations would
> be handled by EMF. If there is I'd love to hear about it - if not I'd
> be happy if you could give me a hint where to find a book about EMF
> that is worth its money.
Automatic merging and coexistence of generated and hand written code is
well support (and heavily exploited in a most clients). The
"Customizing the generated implementation classes" section of
introductory overview explains how:

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html

The EMF book, in my very biased opinion, is well worth the money:
http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&rl=1
< http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&rl=1>
>
> To summarize my requirements:
> 1. generate a model from potentially already existing code
You'd need to add @model annotations to produce an ecore model.
> 2. allow for restrictions specified in the model
EMF's XSD to Ecore mapping supports all the XML Schema's simple type
facet constraints and they can be controlled via annotations in our model:
< http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf>

http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf

> 3. offer convenient method of validating data against the model's
> restrictions
EMF has a validation framework.

http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html

> 4. on model change have "dependant" code (mostly dialogs and other
> user input/output stuff) update (maybe even automatically during
> prototyping?)
EMF models support notification that allows any view to keep in sync.
(EMF even has a ChangeRecorder that can record all model changes so that
they can be undone.)
> 5. not dependant on RCP (even if UI stuff has to be generated by the
> framework)
EMF models work standalone with no Eclipse dependencies.
>
> My library currently does those things in the following way
> 1. reflection of java classes
> 2. annotations for the properties (at the setters)
> 3. using a validator class that validates against a XSDTypeDefinition
> 4. during prototyping dialogs are generated on the fly at runtime
> 5. dialogs are merely "XML Editors" so a implementation for virtually
> any platform (SWT, Swing, XHTML/Ajax) is straight forward
>
> Now if that is possible with EMF and you could point me to some good
> documentation I'd be more than happy to give it a real shot.
Maybe you have enough now to evaluate... ;-)

At EclipseCon Michael Scharf did a really very cool presentation where
he reflectively populates an entire dialog with nice controls just from
annotations on the Ecore model

http://www.eclipsecon.org/2006/Sub.do?id=423

I'm not sure if EMF's support for dynamic models would be interesting
for you, but you might want to have a look at this presentation and
especially at the sample project:
< http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding>

http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding

>
> Thanks for your help,
>
> Alex


--------------080506040806070101050502
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">
Alex,<br>
<br>
Comments below...<br>
<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">Hi Ed,
<br>
<br>
comments see below :)
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">It pretty much sounds like everything you
need is already there.&nbsp; Mostly it seems your concern is that there is
perhaps too much is already there.&nbsp; I.e., what else would you need?
<br>
</blockquote>
<br>
I indeed looks like this is the case. But maybe it's just me, but I
couldn't really find much more about EMF than "generate a fully blown
RCP application from various model definitions" - with lots of code
generated underway. This is definitely _not_ what I want.
<br>
</blockquote>
If you put your rose colored glasses on, you can ignore anything you
don't want and see only what you do need, i.e., code that implements
your model.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
While I see that automatic code generation has its advantages I worked
with some such components (like VE for example) and most of time they
make things worse instead of helping out - especially when things have
to be combined with user-written code - then back in the model
definition a change occurs so some code has to be generated again and
this time merged with the user-written parts - things like that.
<br>
I couldn't really find any documentation on how such situations would
be handled by EMF. If there is I'd love to hear about it - if not I'd
be happy if you could give me a hint where to find a book about EMF
that is worth its money.
<br>
</blockquote>
Automatic merging and coexistence of generated and hand written code is
well support (and heavily exploited in a most clients).&nbsp; The
"Customizing the generated implementation classes" section of
introductory overview explains how:<br>
<blockquote><a
href=" http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html"> http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html</a><br>
</blockquote>
The EMF book, in my very biased opinion, is well worth the money:&nbsp; <a
href=" http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&amp;rl=1"> http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&amp;rl=1</a><br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
To summarize my requirements:
<br>
1. generate a model from potentially already existing code
<br>
</blockquote>
You'd need to add @model annotations to produce an ecore model.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">2.
allow for restrictions specified in the model
<br>
</blockquote>
EMF's XSD to Ecore mapping supports all the XML Schema's simple type
facet constraints and they can be controlled via annotations in our
model:<a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"><br>
</a>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">3.
offer convenient method of validating data against the model's
restrictions
<br>
</blockquote>
EMF has a validation framework.&nbsp; <br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html"> http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">4. on
model change have "dependant" code (mostly dialogs and other user
input/output stuff) update (maybe even automatically during
prototyping?)
<br>
</blockquote>
EMF models support notification that allows any view to keep in sync.
(EMF even has a ChangeRecorder that can record all model changes so
that they can be undone.)<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">5. not
dependant on RCP (even if UI stuff has to be generated by the
framework)
<br>
</blockquote>
EMF models work standalone with no Eclipse dependencies.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
My library currently does those things in the following way
<br>
1. reflection of java classes
<br>
2. annotations for the properties (at the setters)
<br>
3. using a validator class that validates against a XSDTypeDefinition
<br>
4. during prototyping dialogs are generated on the fly at runtime
<br>
5. dialogs are merely "XML Editors" so a implementation for virtually
any platform (SWT, Swing, XHTML/Ajax) is straight forward
<br>
<br>
Now if that is possible with EMF and you could point me to some good
documentation I'd be more than happy to give it a real shot.
<br>
</blockquote>
Maybe you have enough now to evaluate... ;-)<br>
<br>
At EclipseCon&nbsp; Michael Scharf did a really very cool presentation where
he reflectively populates an entire dialog with nice controls just from
annotations on the Ecore model<br>
<blockquote><a href="http://www.eclipsecon.org/2006/Sub.do?id=423">http://www.eclipsecon.org/2006/Sub.do?id=423</a><br>
</blockquote>
I'm not sure if EMF's support for dynamic models would be interesting
for you, but you might want to have a look at this presentation and
especially at the sample project:<a
href=" http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding"><br>
</a>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding"> http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
Thanks for your help,
<br>
<br>
Alex
<br>
</blockquote>
<br>
</body>
</html>

--------------080506040806070101050502--
Re: Extension to XSD? [message #68443 is a reply to message #68432] Fri, 16 June 2006 20:27 Go to previous message
Eclipse User
Originally posted by: stockina.fmi.uni-passau.de

Ed,

I really want to thank you for your invaluable input. While I did learn
a lot about model-modelling in my little journey on XSD your hints
showed me the strenghts of EMF and I'm sure I'll use it for the task at
hand.
And yet another Addison-Wesley joins my book-shelf - I hope your opinion
is not all too biased although this would be understandable ;) But if
the book is just half as helpful as your comments in the newsgroup it
surely is worth the money.

Again, thanks for your help! And I hope you don't mind if I get back to
you with questions on EMF - being still a student at university my
desire to learn obviously longs for people like you ;). EMF is simply
the closest thing I've seen to the idealistic view of software
engineering I enjoy at my courses.

Cheers,
Alex
Re: Extension to XSD? [message #598211 is a reply to message #68360] Wed, 14 June 2006 21:45 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020303040601090508070503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex,

I can't answer questions about how to do things with JAXB because I
don't know how that works....

In EMF we do very similar things with annotations, e.g.,
ecore:reference, to map XML Schema to Ecore:

http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf

It's an interesting idea to try to constraint a wildcard in this way.
Have you considered just using substitution groups since they provide
the type constraint directly?


Alexander Stockinger wrote:
> Hello,
>
> I want to extend the XSD validator by a self-written feature.
> Basically what I want to accomplish it to restrain a <xsd:any/> tag in
> a complex type definition to only accept elements of types that extend
> a specific base type (some sort of polymorphism if you want). so what
> I want to end up with is something like <xsd:any
> typeRestriction="ns0:MyBaseType"/>.
>
> I guess specifying this in a valid XSD document wouldn't be all that
> hard - simply provide a namespace for the typeRestriction attribute
> and things should go well, shouldn't they? my question is: how to
> integrate that in a JAXB compliant XSD validator? Is there a easy way
> to do what I want or do I need to implement my own XSD validator
> (which would indeed be overkill).
>
> Thanks for your help,
>
> Alex


--------------020303040601090508070503
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
I can't answer questions about how to do things with JAXB because I
don't know how that works....<br>
<br>
In EMF we do very similar things with annotations, e.g.,
ecore:reference, to map XML Schema to Ecore:<br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf</a><br>
</blockquote>
It's an interesting idea to try to constraint a wildcard in this way.&nbsp;
Have you considered just using substitution groups since they provide
the type constraint directly?<br>
<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6prqc$2cj$1@utils.eclipse.org" type="cite">Hello,
<br>
<br>
I want to extend the XSD validator by a self-written feature. Basically
what I want to accomplish it to restrain a &lt;xsd:any/&gt; tag in a
complex type definition to only accept elements of types that extend a
specific base type (some sort of polymorphism if you want). so what I
want to end up with is something like &lt;xsd:any
typeRestriction="ns0:MyBaseType"/&gt;.
<br>
<br>
I guess specifying this in a valid XSD document wouldn't be all that
hard - simply provide a namespace for the typeRestriction attribute and
things should go well, shouldn't they? my question is: how to integrate
that in a JAXB compliant XSD validator? Is there a easy way to do what
I want or do I need to implement my own XSD validator (which would
indeed be overkill).
<br>
<br>
Thanks for your help,
<br>
<br>
Alex
<br>
</blockquote>
<br>
</body>
</html>

--------------020303040601090508070503--
Re: Extension to XSD? [message #598219 is a reply to message #68370] Thu, 15 June 2006 07:12 Go to previous message
Alexander Stockinger is currently offline Alexander Stockinger
Messages: 8
Registered: July 2009
Junior Member
Hello Ed,

>
> It's an interesting idea to try to constraint a wildcard in this way.
> Have you considered just using substitution groups since they provide
> the type constraint directly?
>
I read about substitution groups but basically what scared me away was
this sentence in the W3C XSD tutorial: "Note that all elements in the
substitutionGroup (the head element and the substitutable elements) must
be declared as global elements, otherwise it will not work!"

I want to use this for specifying a schema for SWT based dialog "style
sheets". So What I try is: Have the complexType "swtDialog" specify that
it only accepts elements of the abstract complex type "swtControl" but
without the need to specify each subtype of "swtControl" as an element
in "swtDialog".

With the requirement that elements in substitution groups must be global
I would allow dialog style-sheets that have a control as root element -
wouldn't I? That is surely not what I want to achieve.



Indeed I am playing around with something like EMF with the ability to
generate a model at runtime. The basic idea is to store the model
metadata in an XSD in memory and expose a DOM-implementation that offers
XML-style access to a model instance. That way you immediately get a
nice feature set virtually for free: XPath, XForms etc. I also allow
"reflection" of the DOM model by exposing the XSDTypeDefinition for a
Element via Node.getFeature().
The models can be specified using "ModelContributors". The only one I
implemented, yet, uses reflection at runtime on a java class hierarchy.
However one could also imagine using SQL, already existing XSD documents
or auto-generated code (where the advantage of auto-generated code
clearly is speed since it doesn't need to rely on reflection).

Back on topic. I just mention it because I think it's funny: You create
models from XSDs while my approach generates XSDs from models. The
original question is for a SWT based dialog front end that enables
editing the DOM structure of the model.

Thanks for you help,
Alex
Re: Extension to XSD? [message #598225 is a reply to message #68380] Thu, 15 June 2006 11:18 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040109040706070009010507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex,

Comments below.

Alexander Stockinger wrote:
> Hello Ed,
>
>>
>> It's an interesting idea to try to constraint a wildcard in this
>> way. Have you considered just using substitution groups since they
>> provide the type constraint directly?
>>
> I read about substitution groups but basically what scared me away was
> this sentence in the W3C XSD tutorial: "Note that all elements in the
> substitutionGroup (the head element and the substitutable elements)
> must be declared as global elements, otherwise it will not work!"
This is true, but wildcards only allow global elements as well, except
in some odd restriction scenarios.
> I want to use this for specifying a schema for SWT based dialog "style
> sheets". So What I try is: Have the complexType "swtDialog" specify
> that it only accepts elements of the abstract complex type
> "swtControl" but without the need to specify each subtype of
> "swtControl" as an element in "swtDialog".
Sounds like defining a substitution group element head of perhaps some
abstract base type swtControl. Any schema could then define an element
of a type derived from swtControl and use it in your swtDialog type.
>
> With the requirement that elements in substitution groups must be
> global I would allow dialog style-sheets that have a control as root
> element - wouldn't I? That is surely not what I want to achieve.
I'm not sure how you'll avoid the root element thing with your wildcard
approach.
>
>
>
> Indeed I am playing around with something like EMF with the ability to
> generate a model at runtime. The basic idea is to store the model
> metadata in an XSD in memory and expose a DOM-implementation that
> offers XML-style access to a model instance. That way you immediately
> get a nice feature set virtually for free: XPath, XForms etc. I also
> allow "reflection" of the DOM model by exposing the XSDTypeDefinition
> for a Element via Node.getFeature().
> The models can be specified using "ModelContributors". The only one I
> implemented, yet, uses reflection at runtime on a java class
> hierarchy. However one could also imagine using SQL, already existing
> XSD documents or auto-generated code (where the advantage of
> auto-generated code clearly is speed since it doesn't need to rely on
> reflection).
Yep. Sure sounds like EMF.
>
> Back on topic. I just mention it because I think it's funny: You
> create models from XSDs while my approach generates XSDs from models.
EMF does both. Given a model you can export it as a schema. So it's
possible to convert XSD to Ecore and to generate Java from that Ecore;
it's also possible to take advantage of @model annotations to go in the
reverse direction and generate Ecore from the Java, and generate a
schema from the Ecore. For many schemas, this XSD -> Ecore -> Java ->
Ecore -> XSD is effectively a round trip...
> The original question is for a SWT based dialog front end that enables
> editing the DOM structure of the model.
EMF also lets you save a resource as DOM and maintains a mapping between
the DOM and the model so that you can apply XPath to the DOM and map the
result of the valuation back onto the model.
>
> Thanks for you help,
> Alex
Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
< http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
to compare what you are trying to achieve with what's already
available? You might find that what you are trying to build could be
accomplished much more easily...

--------------040109040706070009010507
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Comments below.<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">Hello
Ed,
<br>
<br>
<blockquote type="cite"><br>
It's an interesting idea to try to constraint a wildcard in this way.&nbsp;
Have you considered just using substitution groups since they provide
the type constraint directly?
<br>
<br>
</blockquote>
I read about substitution groups but basically what scared me away was
this sentence in the W3C XSD tutorial: "Note that all elements in the
substitutionGroup (the head element and the substitutable elements)
must be declared as global elements, otherwise it will not work!"
<br>
</blockquote>
This is true, but wildcards only allow global elements as well, except
in some odd restriction scenarios.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">I want
to use this for specifying a schema for SWT based dialog "style
sheets". So What I try is: Have the complexType "swtDialog" specify
that it only accepts elements of the abstract complex type "swtControl"
but without the need to specify each subtype of "swtControl" as an
element in "swtDialog".
<br>
</blockquote>
Sounds like defining a substitution group element&nbsp; head of perhaps some
abstract base type swtControl.&nbsp;&nbsp; Any schema could then define an
element of a type derived from swtControl and use it in your swtDialog
type.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
With the requirement that elements in substitution groups must be
global I would allow dialog style-sheets that have a control as root
element - wouldn't I? That is surely not what I want to achieve.
<br>
</blockquote>
I'm not sure how you'll avoid the root element thing with your wildcard
approach.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
<br>
<br>
Indeed I am playing around with something like EMF with the ability to
generate a model at runtime. The basic idea is to store the model
metadata in an XSD in memory and expose a DOM-implementation that
offers &nbsp;XML-style access to a model instance. That way you immediately
get a nice feature set virtually for free: XPath, XForms etc. I also
allow "reflection" of the DOM model by exposing the XSDTypeDefinition
for a Element via Node.getFeature().
<br>
The models can be specified using "ModelContributors". The only one I
implemented, yet, uses reflection at runtime on a java class hierarchy.
However one could also imagine using SQL, already existing XSD
documents or auto-generated code (where the advantage of auto-generated
code clearly is speed since it doesn't need to rely on reflection).
<br>
</blockquote>
Yep.&nbsp; Sure sounds like EMF.<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
Back on topic. I just mention it because I think it's funny: You create
models from XSDs while my approach generates XSDs from models. </blockquote>
EMF does both.&nbsp; Given a model you can export it as a schema.&nbsp; So it's
possible to convert XSD to Ecore and to generate Java from that Ecore;
it's also possible to take advantage of @model annotations to go in the
reverse direction and generate Ecore from the Java, and generate a
schema from the Ecore.&nbsp; For many schemas, this XSD -&gt; Ecore -&gt;
Java -&gt; Ecore -&gt; XSD is effectively a round trip...<br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite">The
original question is for a SWT based dialog front end that enables
editing the DOM structure of the model.
<br>
</blockquote>
EMF also lets you save a resource as DOM and maintains a mapping
between the DOM and the model so that you can apply XPath to the DOM
and map the result of the valuation back onto the model.&nbsp; <br>
<blockquote cite="mide6r18p$o5e$1@utils.eclipse.org" type="cite"><br>
Thanks for you help,
<br>
Alex
<br>
</blockquote>
Have you tried <a
href=" http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html">
Tutorial: Generating an EMF 2.1 Model using XML Schema</a> to compare
what you are trying to achieve with what's already available?&nbsp; You
might find that what you are trying to build could be accomplished much
more easily...<br>
</body>
</html>

--------------040109040706070009010507--
Re: Extension to XSD? [message #598231 is a reply to message #68391] Fri, 16 June 2006 06:27 Go to previous message
Alexander Stockinger is currently offline Alexander Stockinger
Messages: 8
Registered: July 2009
Junior Member
Hello Ed,

Comments below.

Ed Merks wrote:
>> I read about substitution groups but basically what scared me away was
>> this sentence in the W3C XSD tutorial: "Note that all elements in the
>> substitutionGroup (the head element and the substitutable elements)
>> must be declared as global elements, otherwise it will not work!"
>
> This is true, but wildcards only allow global elements as well, except
> in some odd restriction scenarios.
>
>> I want to use this for specifying a schema for SWT based dialog "style
>> sheets". So What I try is: Have the complexType "swtDialog" specify
>> that it only accepts elements of the abstract complex type
>> "swtControl" but without the need to specify each subtype of
>> "swtControl" as an element in "swtDialog".
>
> Sounds like defining a substitution group element head of perhaps some
> abstract base type swtControl. Any schema could then define an element
> of a type derived from swtControl and use it in your swtDialog type.
>
>>
>> With the requirement that elements in substitution groups must be
>> global I would allow dialog style-sheets that have a control as root
>> element - wouldn't I? That is surely not what I want to achieve.
>
> I'm not sure how you'll avoid the root element thing with your wildcard
> approach.
>
While the root element thing still bugs me it's probably the most
suitable way to go - at least it allows for validation of a dialog style
XML file.

> EMF also lets you save a resource as DOM and maintains a mapping between
> the DOM and the model so that you can apply XPath to the DOM and map the
> result of the valuation back onto the model.
>
That sounds _exactly_ like the thing I'm trying to accomplish.

>
> Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
> < http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
> to compare what you are trying to achieve with what's already
> available? You might find that what you are trying to build could be
> accomplished much more easily...

I already took a look at this tutorial, but everything about EMF I found
until now basically involved auto-generated code. This is not the
direction I want to go. I am more the "write clean model code and then
have a framework to do its best to create dialogs from it" - guy.

Indeed I am using a @Model annotation as well to mark getters/setters. I
also introduced a @Namespace tag for classes since I also allow for
other model contributors (say for SQL or XSD) that in rare cases might
produce naming conflicts.
I'm also using a @Restriction annotation on setters to define XSD-style
restrictions on the values of properties.

I think the main difference between the two approaches is that for EMF
you always need some kind of model description (XSD, Java interfaces,
UML etc.) to generate the model code while in my library you happily
write your java classes as normal (standard getter/setter conventions),
test them with JUnit or whatever you like and then you just throw the
finished classes along with some annotations into the pot - what you get
is a nice DOM structure with XSD-"reflection" and a toolkit of
dialog-classes that automagically offer editing facilities for the DOM
structure.

Probably I should really go ahead an use EMF for what I want to
accomplish but I'm more like "as little code as possible" (I always have
the concept of "less code - less bugs" in mind) and so EMF just involves
to much "redundant" specification for my taste. I do indeed like the
concept of EMF and I wish I heard earlier about it - would have saved me
a great deal of work. But right now I want to go a step further and have
the framework "interpret" the semantics of my class hierarchy.

I'm eager to hear your comments - maybe I just don't know enough about
EMF to see that it already offers what I want.

Thanks for your input,
Alex
Re: Extension to XSD? [message #598239 is a reply to message #68399] Fri, 16 June 2006 11:44 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
Alex,

Comments below.

Alexander Stockinger wrote:
> Hello Ed,
>
> Comments below.
>
> Ed Merks wrote:
>>> I read about substitution groups but basically what scared me away
>>> was this sentence in the W3C XSD tutorial: "Note that all elements
>>> in the substitutionGroup (the head element and the substitutable
>>> elements) must be declared as global elements, otherwise it will not
>>> work!"
>>
>> This is true, but wildcards only allow global elements as well,
>> except in some odd restriction scenarios.
>>
>>> I want to use this for specifying a schema for SWT based dialog
>>> "style sheets". So What I try is: Have the complexType "swtDialog"
>>> specify that it only accepts elements of the abstract complex type
>>> "swtControl" but without the need to specify each subtype of
>>> "swtControl" as an element in "swtDialog".
>>
>> Sounds like defining a substitution group element head of perhaps
>> some abstract base type swtControl. Any schema could then define an
>> element of a type derived from swtControl and use it in your
>> swtDialog type.
>>
>>>
>>> With the requirement that elements in substitution groups must be
>>> global I would allow dialog style-sheets that have a control as root
>>> element - wouldn't I? That is surely not what I want to achieve.
>>
>> I'm not sure how you'll avoid the root element thing with your
>> wildcard approach.
>>
> While the root element thing still bugs me it's probably the most
> suitable way to go - at least it allows for validation of a dialog
> style XML file.
>
>> EMF also lets you save a resource as DOM and maintains a mapping
>> between the DOM and the model so that you can apply XPath to the DOM
>> and map the result of the valuation back onto the model.
> That sounds _exactly_ like the thing I'm trying to accomplish.
In the org.eclipse.jet plugin (part of the EMFT project) there is even
an XPath evaluator than can evaluate XPath directly against your objects
without at DOM.
>
>>
>> Have you tried Tutorial: Generating an EMF 2.1 Model using XML Schema
>> < http://www.eclipse.org/emf/docs.php?doc=tutorials/xlibmod/xl ibmod.html>
>> to compare what you are trying to achieve with what's already
>> available? You might find that what you are trying to build could be
>> accomplished much more easily...
>
> I already took a look at this tutorial, but everything about EMF I
> found until now basically involved auto-generated code. This is not
> the direction I want to go. I am more the "write clean model code and
> then have a framework to do its best to create dialogs from it" - guy.
This seems questionable. You must have a lot of time on your hands to
do so many things manually...
>
> Indeed I am using a @Model annotation as well to mark getters/setters.
> I also introduced a @Namespace tag for classes since I also allow for
> other model contributors (say for SQL or XSD) that in rare cases might
> produce naming conflicts.
> I'm also using a @Restriction annotation on setters to define
> XSD-style restrictions on the values of properties.
The joy of @annotations. I can imagine then day when there will be more
of these than anything else in the code. This seems not significantly
different from using EMF's @model annotations within the Javadoc.
>
> I think the main difference between the two approaches is that for EMF
> you always need some kind of model description (XSD, Java interfaces,
> UML etc.) to generate the model code while in my library you happily
> write your java classes as normal (standard getter/setter
> conventions), test them with JUnit or whatever you like and then you
> just throw the finished classes along with some annotations into the
> pot - what you get is a nice DOM structure with XSD-"reflection" and a
> toolkit of dialog-classes that automagically offer editing facilities
> for the DOM structure.
Your normal interfaces with getters and setters is a model definition.
EMF generates JUnit tests for you.
>
> Probably I should really go ahead an use EMF for what I want to
> accomplish but I'm more like "as little code as possible" (I always
> have the concept of "less code - less bugs" in mind) and so EMF just
> involves to much "redundant" specification for my taste. I do indeed
> like the concept of EMF and I wish I heard earlier about it - would
> have saved me a great deal of work. But right now I want to go a step
> further and have the framework "interpret" the semantics of my class
> hierarchy.
I'm more of the opinion that the more hand written code the more hand
written bugs you'll have. ;-)
>
> I'm eager to hear your comments - maybe I just don't know enough about
> EMF to see that it already offers what I want.
It pretty much sounds like everything you need is already there. Mostly
it seems your concern is that there is perhaps too much is already
there. I.e., what else would you need?
>
> Thanks for your input,
> Alex
Re: Extension to XSD? [message #598245 is a reply to message #68410] Fri, 16 June 2006 12:17 Go to previous message
Alexander Stockinger is currently offline Alexander Stockinger
Messages: 8
Registered: July 2009
Junior Member
Hi Ed,

comments see below :)

Ed Merks wrote:

> It pretty much sounds like everything you need is already there. Mostly
> it seems your concern is that there is perhaps too much is already
> there. I.e., what else would you need?

I indeed looks like this is the case. But maybe it's just me, but I
couldn't really find much more about EMF than "generate a fully blown
RCP application from various model definitions" - with lots of code
generated underway. This is definitely _not_ what I want.

While I see that automatic code generation has its advantages I worked
with some such components (like VE for example) and most of time they
make things worse instead of helping out - especially when things have
to be combined with user-written code - then back in the model
definition a change occurs so some code has to be generated again and
this time merged with the user-written parts - things like that.
I couldn't really find any documentation on how such situations would be
handled by EMF. If there is I'd love to hear about it - if not I'd be
happy if you could give me a hint where to find a book about EMF that is
worth its money.

To summarize my requirements:
1. generate a model from potentially already existing code
2. allow for restrictions specified in the model
3. offer convenient method of validating data against the model's
restrictions
4. on model change have "dependant" code (mostly dialogs and other user
input/output stuff) update (maybe even automatically during prototyping?)
5. not dependant on RCP (even if UI stuff has to be generated by the
framework)

My library currently does those things in the following way
1. reflection of java classes
2. annotations for the properties (at the setters)
3. using a validator class that validates against a XSDTypeDefinition
4. during prototyping dialogs are generated on the fly at runtime
5. dialogs are merely "XML Editors" so a implementation for virtually
any platform (SWT, Swing, XHTML/Ajax) is straight forward

Now if that is possible with EMF and you could point me to some good
documentation I'd be more than happy to give it a real shot.

Thanks for your help,

Alex
Re: Extension to XSD? [message #598254 is a reply to message #68421] Fri, 16 June 2006 12:49 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080506040806070101050502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex,

Comments below...


Alexander Stockinger wrote:
> Hi Ed,
>
> comments see below :)
>
> Ed Merks wrote:
>
>> It pretty much sounds like everything you need is already there.
>> Mostly it seems your concern is that there is perhaps too much is
>> already there. I.e., what else would you need?
>
> I indeed looks like this is the case. But maybe it's just me, but I
> couldn't really find much more about EMF than "generate a fully blown
> RCP application from various model definitions" - with lots of code
> generated underway. This is definitely _not_ what I want.
If you put your rose colored glasses on, you can ignore anything you
don't want and see only what you do need, i.e., code that implements
your model.
>
> While I see that automatic code generation has its advantages I worked
> with some such components (like VE for example) and most of time they
> make things worse instead of helping out - especially when things have
> to be combined with user-written code - then back in the model
> definition a change occurs so some code has to be generated again and
> this time merged with the user-written parts - things like that.
> I couldn't really find any documentation on how such situations would
> be handled by EMF. If there is I'd love to hear about it - if not I'd
> be happy if you could give me a hint where to find a book about EMF
> that is worth its money.
Automatic merging and coexistence of generated and hand written code is
well support (and heavily exploited in a most clients). The
"Customizing the generated implementation classes" section of
introductory overview explains how:

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html

The EMF book, in my very biased opinion, is well worth the money:
http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&rl=1
< http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&rl=1>
>
> To summarize my requirements:
> 1. generate a model from potentially already existing code
You'd need to add @model annotations to produce an ecore model.
> 2. allow for restrictions specified in the model
EMF's XSD to Ecore mapping supports all the XML Schema's simple type
facet constraints and they can be controlled via annotations in our model:
< http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf>

http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf

> 3. offer convenient method of validating data against the model's
> restrictions
EMF has a validation framework.

http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html

> 4. on model change have "dependant" code (mostly dialogs and other
> user input/output stuff) update (maybe even automatically during
> prototyping?)
EMF models support notification that allows any view to keep in sync.
(EMF even has a ChangeRecorder that can record all model changes so that
they can be undone.)
> 5. not dependant on RCP (even if UI stuff has to be generated by the
> framework)
EMF models work standalone with no Eclipse dependencies.
>
> My library currently does those things in the following way
> 1. reflection of java classes
> 2. annotations for the properties (at the setters)
> 3. using a validator class that validates against a XSDTypeDefinition
> 4. during prototyping dialogs are generated on the fly at runtime
> 5. dialogs are merely "XML Editors" so a implementation for virtually
> any platform (SWT, Swing, XHTML/Ajax) is straight forward
>
> Now if that is possible with EMF and you could point me to some good
> documentation I'd be more than happy to give it a real shot.
Maybe you have enough now to evaluate... ;-)

At EclipseCon Michael Scharf did a really very cool presentation where
he reflectively populates an entire dialog with nice controls just from
annotations on the Ecore model

http://www.eclipsecon.org/2006/Sub.do?id=423

I'm not sure if EMF's support for dynamic models would be interesting
for you, but you might want to have a look at this presentation and
especially at the sample project:
< http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding>

http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding

>
> Thanks for your help,
>
> Alex


--------------080506040806070101050502
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">
Alex,<br>
<br>
Comments below...<br>
<br>
<br>
Alexander Stockinger wrote:
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">Hi Ed,
<br>
<br>
comments see below :)
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">It pretty much sounds like everything you
need is already there.&nbsp; Mostly it seems your concern is that there is
perhaps too much is already there.&nbsp; I.e., what else would you need?
<br>
</blockquote>
<br>
I indeed looks like this is the case. But maybe it's just me, but I
couldn't really find much more about EMF than "generate a fully blown
RCP application from various model definitions" - with lots of code
generated underway. This is definitely _not_ what I want.
<br>
</blockquote>
If you put your rose colored glasses on, you can ignore anything you
don't want and see only what you do need, i.e., code that implements
your model.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
While I see that automatic code generation has its advantages I worked
with some such components (like VE for example) and most of time they
make things worse instead of helping out - especially when things have
to be combined with user-written code - then back in the model
definition a change occurs so some code has to be generated again and
this time merged with the user-written parts - things like that.
<br>
I couldn't really find any documentation on how such situations would
be handled by EMF. If there is I'd love to hear about it - if not I'd
be happy if you could give me a hint where to find a book about EMF
that is worth its money.
<br>
</blockquote>
Automatic merging and coexistence of generated and hand written code is
well support (and heavily exploited in a most clients).&nbsp; The
"Customizing the generated implementation classes" section of
introductory overview explains how:<br>
<blockquote><a
href=" http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html"> http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /org.eclipse.emf/doc/org.eclipse.emf.doc/references/overview /EMF.html</a><br>
</blockquote>
The EMF book, in my very biased opinion, is well worth the money:&nbsp; <a
href=" http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&amp;rl=1"> http://www.awprofessional.com/bookstore/product.asp?isbn=013 1425420&amp;rl=1</a><br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
To summarize my requirements:
<br>
1. generate a model from potentially already existing code
<br>
</blockquote>
You'd need to add @model annotations to produce an ecore model.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">2.
allow for restrictions specified in the model
<br>
</blockquote>
EMF's XSD to Ecore mapping supports all the XML Schema's simple type
facet constraints and they can be controlled via annotations in our
model:<a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"><br>
</a>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf"> http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">3.
offer convenient method of validating data against the model's
restrictions
<br>
</blockquote>
EMF has a validation framework.&nbsp; <br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html"> http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">4. on
model change have "dependant" code (mostly dialogs and other user
input/output stuff) update (maybe even automatically during
prototyping?)
<br>
</blockquote>
EMF models support notification that allows any view to keep in sync.
(EMF even has a ChangeRecorder that can record all model changes so
that they can be undone.)<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite">5. not
dependant on RCP (even if UI stuff has to be generated by the
framework)
<br>
</blockquote>
EMF models work standalone with no Eclipse dependencies.<br>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
My library currently does those things in the following way
<br>
1. reflection of java classes
<br>
2. annotations for the properties (at the setters)
<br>
3. using a validator class that validates against a XSDTypeDefinition
<br>
4. during prototyping dialogs are generated on the fly at runtime
<br>
5. dialogs are merely "XML Editors" so a implementation for virtually
any platform (SWT, Swing, XHTML/Ajax) is straight forward
<br>
<br>
Now if that is possible with EMF and you could point me to some good
documentation I'd be more than happy to give it a real shot.
<br>
</blockquote>
Maybe you have enough now to evaluate... ;-)<br>
<br>
At EclipseCon&nbsp; Michael Scharf did a really very cool presentation where
he reflectively populates an entire dialog with nice controls just from
annotations on the Ecore model<br>
<blockquote><a href="http://www.eclipsecon.org/2006/Sub.do?id=423">http://www.eclipsecon.org/2006/Sub.do?id=423</a><br>
</blockquote>
I'm not sure if EMF's support for dynamic models would be interesting
for you, but you might want to have a look at this presentation and
especially at the sample project:<a
href=" http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding"><br>
</a>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding"> http://www.eclipse.org/emf/docs.php#eclipsecon2006xmlbinding</a><br>
</blockquote>
<blockquote cite="mide6u7di$ua7$2@utils.eclipse.org" type="cite"><br>
Thanks for your help,
<br>
<br>
Alex
<br>
</blockquote>
<br>
</body>
</html>

--------------080506040806070101050502--
Re: Extension to XSD? [message #598261 is a reply to message #68432] Fri, 16 June 2006 20:27 Go to previous message
Alexander Stockinger is currently offline Alexander Stockinger
Messages: 8
Registered: July 2009
Junior Member
Ed,

I really want to thank you for your invaluable input. While I did learn
a lot about model-modelling in my little journey on XSD your hints
showed me the strenghts of EMF and I'm sure I'll use it for the task at
hand.
And yet another Addison-Wesley joins my book-shelf - I hope your opinion
is not all too biased although this would be understandable ;) But if
the book is just half as helpful as your comments in the newsgroup it
surely is worth the money.

Again, thanks for your help! And I hope you don't mind if I get back to
you with questions on EMF - being still a student at university my
desire to learn obviously longs for people like you ;). EMF is simply
the closest thing I've seen to the idealistic view of software
engineering I enjoy at my courses.

Cheers,
Alex
Previous Topic:Extension to XSD?
Next Topic:Schema validation problem
Goto Forum:
  


Current Time: Sun Oct 26 03:48:56 GMT 2014

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

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