|
| Re: Best way to extend XSD editor [message #61636 is a reply to message #61589] |
Tue, 14 June 2005 16:21   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------030105070701090507020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dave,
I've added comments below inline.
Dave Bolt wrote:
>We need to build a set of plug-ins that are extensions to the built-in XSD
>editor. I'm looking for advice on how best to do the following:
>
>We want to make use of the xs:annotation/xs:appinfo feature of XML schema to
>embed some extra processing information into the schema. We will use these
>additional machine-readable annotations to facilitate code generation logic
>that is being built into other plugins on top of JDT. For an analogy for
>what we are trying to accomplish, look at how JAXB can use inline XSD
>annotations to provide customization of the generated JAXB binding classes.
>
>
>
This is also just like we do for our XML Schema to Ecore conversion:
XML Schema to Ecore Mapping
< http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf>
>Here is a high level use case.
>
>The user would open an XML Schema XSD file using the XSD editor. The editor
>and associated views would offer right-click menu options to add our
>annotation tags to each customType and/or element in the XSD. The
>implementation of the GUI would be similar to the Refactoring and Source
>pop-up windows that you see in JDT.
>
>
>
Popup actions are easy to add via registered popup. There's an example
of a popup action for EClass in org.eclipse.emf.ecore.editor.plugin.xml.
This allows your popup to appear in editors you've never modified.
>We also want to add a background incremental builder that would "compile"
>the XSD and add problem markers to all of the customTypes and elements that
>are missing annotations.
>
>
>
I don't have much experience with builders (although we do have one to
convert JET templates to Java source). We usually do stuff like this
via an explicit action.
>The annotations themselves are bindings to other classes in our object model
>and JAXB binding layer. The ultimate goal of the metadata is to help the
>developer build a EJB session bean that reads data from an EJB entity
>bean-based object model and write the data to a JAXB API derived from an XML
>schema. A lot of this code is boilerplate in nature and could be generated
>if we could map each customType/element to it's underlying EJB and
>field/relationship.
>
>
>
Maybe you should consider using EMF instead of JAXB. We provide roughly
equivalent function.
>Does the XSD editor that you see in 3.0.x use EMF in the background to model
>the structure of the document? Does this API fully support the annotation
>features of the XML schema spec?
>
>
>
Yes, the sample editor uses the XSD model to implement its support. The
XSD model does support working with annotations, but the low level
annotations contents themselves will require you to use DOM, since
annotations can be arbitrary DOM. There are examples of how to do this
in XSDPrototypicalSchema.
>As an alternative approach we would use an external binding annotation
>mechanism. We would design an XML schema that describes our binding
>metadata. We would use EMF to build a custom editor for documents that
>conform to this approach. To feed data to the editor we would run the XSD
>file through a standard XSLT stylesheet to produce a derivative annotation
>file that conforms to the EMF schema. This seems easier because I'm not
>trying to shoehorn functionality into places where it might not fit.
>
>
>
This is an interesting approach too. One day well want to do something
like this for our Ecore annotations so that it's easier to annotate a
schema that can't be changed.
>So what do you think? What is the best fit for this type of problem?
>
>
>
Probably you want to start simple and get some cool stuff working
quickly. I think a registered popup action is the fastest way to get
started. Probably the popup action will even work with the nice XML
Schema editor in the WTP project (which is also based on the XSD model)
and even in the WSDL editor...
>Thanks
>Dave
>
>
>
>
>
>
--------------030105070701090507020601
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">
Dave,<br>
<br>
I've added comments below inline.<br>
<br>
<br>
Dave Bolt wrote:
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">We need to build a set of plug-ins that are extensions to the built-in XSD
editor. I'm looking for advice on how best to do the following:
We want to make use of the xs:annotation/xs:appinfo feature of XML schema to
embed some extra processing information into the schema. We will use these
additional machine-readable annotations to facilitate code generation logic
that is being built into other plugins on top of JDT. For an analogy for
what we are trying to accomplish, look at how JAXB can use inline XSD
annotations to provide customization of the generated JAXB binding classes.
</pre>
</blockquote>
This is also just like we do for our XML Schema to Ecore conversion:<br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf">
XML Schema to Ecore Mapping</a><br>
</blockquote>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Here is a high level use case.
The user would open an XML Schema XSD file using the XSD editor. The editor
and associated views would offer right-click menu options to add our
annotation tags to each customType and/or element in the XSD. The
implementation of the GUI would be similar to the Refactoring and Source
pop-up windows that you see in JDT.
</pre>
</blockquote>
Popup actions are easy to add via registered popup. There's an example
of a popup action for EClass in
org.eclipse.emf.ecore.editor.plugin.xml. This allows your popup to
appear in editors you've never modified.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">We also want to add a background incremental builder that would "compile"
the XSD and add problem markers to all of the customTypes and elements that
are missing annotations.
</pre>
</blockquote>
I don't have much experience with builders (although we do have one to
convert JET templates to Java source). We usually do stuff like this
via an explicit action.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">The annotations themselves are bindings to other classes in our object model
and JAXB binding layer. The ultimate goal of the metadata is to help the
developer build a EJB session bean that reads data from an EJB entity
bean-based object model and write the data to a JAXB API derived from an XML
schema. A lot of this code is boilerplate in nature and could be generated
if we could map each customType/element to it's underlying EJB and
field/relationship.
</pre>
</blockquote>
Maybe you should consider using EMF instead of JAXB. We provide
roughly equivalent function.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Does the XSD editor that you see in 3.0.x use EMF in the background to model
the structure of the document? Does this API fully support the annotation
features of the XML schema spec?
</pre>
</blockquote>
Yes, the sample editor uses the XSD model to implement its support.
The XSD model does support working with annotations, but the low level
annotations contents themselves will require you to use DOM, since
annotations can be arbitrary DOM. There are examples of how to do this
in XSDPrototypicalSchema.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">As an alternative approach we would use an external binding annotation
mechanism. We would design an XML schema that describes our binding
metadata. We would use EMF to build a custom editor for documents that
conform to this approach. To feed data to the editor we would run the XSD
file through a standard XSLT stylesheet to produce a derivative annotation
file that conforms to the EMF schema. This seems easier because I'm not
trying to shoehorn functionality into places where it might not fit.
</pre>
</blockquote>
This is an interesting approach too. One day well want to do something
like this for our Ecore annotations so that it's easier to annotate a
schema that can't be changed.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">So what do you think? What is the best fit for this type of problem?
</pre>
</blockquote>
Probably you want to start simple and get some cool stuff working
quickly. I think a registered popup action is the fastest way to get
started. Probably the popup action will even work with the nice XML
Schema editor in the WTP project (which is also based on the XSD model)
and even in the WSDL editor...<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Thanks
Dave
</pre>
</blockquote>
<br>
</body>
</html>
--------------030105070701090507020601--
|
|
|
|
| Re: Best way to extend XSD editor [message #65920 is a reply to message #61684] |
Mon, 06 February 2006 21:39 |
| Eclipse User |
|
|
|
Originally posted by: gennady_vanin-online.yahoo.com.br
Hello Dave,
I am eager to understand why have u moved from Castor to JAXB?
Correct me,
Guennadi Vanine
> Thanks for the quick reply.
>
> We've been using JAXB for quite some time. It's been working well for
> us as a Java/XML binding where the XML is governed by an XSD file. We
> started with Castor and moved to JAXB over time. Probably too much
> code to move to EMF.
>
> We're probably going to go with the external binding file approach.
> Tweaking the XSD to add annotations would cause many false updates (in
> our project re-release of a shared JAR file) just because an
> annotation was tweaked. So our model is similar to the metadata split
> between the base Ecore model metadata and the EMF code generator
> metadata.
>
> Dave
>
|
|
|
| Re: Best way to extend XSD editor [message #595680 is a reply to message #61589] |
Tue, 14 June 2005 16:21 |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030105070701090507020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Dave,
I've added comments below inline.
Dave Bolt wrote:
>We need to build a set of plug-ins that are extensions to the built-in XSD
>editor. I'm looking for advice on how best to do the following:
>
>We want to make use of the xs:annotation/xs:appinfo feature of XML schema to
>embed some extra processing information into the schema. We will use these
>additional machine-readable annotations to facilitate code generation logic
>that is being built into other plugins on top of JDT. For an analogy for
>what we are trying to accomplish, look at how JAXB can use inline XSD
>annotations to provide customization of the generated JAXB binding classes.
>
>
>
This is also just like we do for our XML Schema to Ecore conversion:
XML Schema to Ecore Mapping
< http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf>
>Here is a high level use case.
>
>The user would open an XML Schema XSD file using the XSD editor. The editor
>and associated views would offer right-click menu options to add our
>annotation tags to each customType and/or element in the XSD. The
>implementation of the GUI would be similar to the Refactoring and Source
>pop-up windows that you see in JDT.
>
>
>
Popup actions are easy to add via registered popup. There's an example
of a popup action for EClass in org.eclipse.emf.ecore.editor.plugin.xml.
This allows your popup to appear in editors you've never modified.
>We also want to add a background incremental builder that would "compile"
>the XSD and add problem markers to all of the customTypes and elements that
>are missing annotations.
>
>
>
I don't have much experience with builders (although we do have one to
convert JET templates to Java source). We usually do stuff like this
via an explicit action.
>The annotations themselves are bindings to other classes in our object model
>and JAXB binding layer. The ultimate goal of the metadata is to help the
>developer build a EJB session bean that reads data from an EJB entity
>bean-based object model and write the data to a JAXB API derived from an XML
>schema. A lot of this code is boilerplate in nature and could be generated
>if we could map each customType/element to it's underlying EJB and
>field/relationship.
>
>
>
Maybe you should consider using EMF instead of JAXB. We provide roughly
equivalent function.
>Does the XSD editor that you see in 3.0.x use EMF in the background to model
>the structure of the document? Does this API fully support the annotation
>features of the XML schema spec?
>
>
>
Yes, the sample editor uses the XSD model to implement its support. The
XSD model does support working with annotations, but the low level
annotations contents themselves will require you to use DOM, since
annotations can be arbitrary DOM. There are examples of how to do this
in XSDPrototypicalSchema.
>As an alternative approach we would use an external binding annotation
>mechanism. We would design an XML schema that describes our binding
>metadata. We would use EMF to build a custom editor for documents that
>conform to this approach. To feed data to the editor we would run the XSD
>file through a standard XSLT stylesheet to produce a derivative annotation
>file that conforms to the EMF schema. This seems easier because I'm not
>trying to shoehorn functionality into places where it might not fit.
>
>
>
This is an interesting approach too. One day well want to do something
like this for our Ecore annotations so that it's easier to annotate a
schema that can't be changed.
>So what do you think? What is the best fit for this type of problem?
>
>
>
Probably you want to start simple and get some cool stuff working
quickly. I think a registered popup action is the fastest way to get
started. Probably the popup action will even work with the nice XML
Schema editor in the WTP project (which is also based on the XSD model)
and even in the WSDL editor...
>Thanks
>Dave
>
>
>
>
>
>
--------------030105070701090507020601
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">
Dave,<br>
<br>
I've added comments below inline.<br>
<br>
<br>
Dave Bolt wrote:
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">We need to build a set of plug-ins that are extensions to the built-in XSD
editor. I'm looking for advice on how best to do the following:
We want to make use of the xs:annotation/xs:appinfo feature of XML schema to
embed some extra processing information into the schema. We will use these
additional machine-readable annotations to facilitate code generation logic
that is being built into other plugins on top of JDT. For an analogy for
what we are trying to accomplish, look at how JAXB can use inline XSD
annotations to provide customization of the generated JAXB binding classes.
</pre>
</blockquote>
This is also just like we do for our XML Schema to Ecore conversion:<br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMa pping.pdf">
XML Schema to Ecore Mapping</a><br>
</blockquote>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Here is a high level use case.
The user would open an XML Schema XSD file using the XSD editor. The editor
and associated views would offer right-click menu options to add our
annotation tags to each customType and/or element in the XSD. The
implementation of the GUI would be similar to the Refactoring and Source
pop-up windows that you see in JDT.
</pre>
</blockquote>
Popup actions are easy to add via registered popup. There's an example
of a popup action for EClass in
org.eclipse.emf.ecore.editor.plugin.xml. This allows your popup to
appear in editors you've never modified.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">We also want to add a background incremental builder that would "compile"
the XSD and add problem markers to all of the customTypes and elements that
are missing annotations.
</pre>
</blockquote>
I don't have much experience with builders (although we do have one to
convert JET templates to Java source). We usually do stuff like this
via an explicit action.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">The annotations themselves are bindings to other classes in our object model
and JAXB binding layer. The ultimate goal of the metadata is to help the
developer build a EJB session bean that reads data from an EJB entity
bean-based object model and write the data to a JAXB API derived from an XML
schema. A lot of this code is boilerplate in nature and could be generated
if we could map each customType/element to it's underlying EJB and
field/relationship.
</pre>
</blockquote>
Maybe you should consider using EMF instead of JAXB. We provide
roughly equivalent function.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Does the XSD editor that you see in 3.0.x use EMF in the background to model
the structure of the document? Does this API fully support the annotation
features of the XML schema spec?
</pre>
</blockquote>
Yes, the sample editor uses the XSD model to implement its support.
The XSD model does support working with annotations, but the low level
annotations contents themselves will require you to use DOM, since
annotations can be arbitrary DOM. There are examples of how to do this
in XSDPrototypicalSchema.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">As an alternative approach we would use an external binding annotation
mechanism. We would design an XML schema that describes our binding
metadata. We would use EMF to build a custom editor for documents that
conform to this approach. To feed data to the editor we would run the XSD
file through a standard XSLT stylesheet to produce a derivative annotation
file that conforms to the EMF schema. This seems easier because I'm not
trying to shoehorn functionality into places where it might not fit.
</pre>
</blockquote>
This is an interesting approach too. One day well want to do something
like this for our Ecore annotations so that it's easier to annotate a
schema that can't be changed.<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">So what do you think? What is the best fit for this type of problem?
</pre>
</blockquote>
Probably you want to start simple and get some cool stuff working
quickly. I think a registered popup action is the fastest way to get
started. Probably the popup action will even work with the nice XML
Schema editor in the WTP project (which is also based on the XSD model)
and even in the WSDL editor...<br>
<blockquote cite="midd8mo5f$ods$1@news.eclipse.org" type="cite">
<pre wrap="">Thanks
Dave
</pre>
</blockquote>
<br>
</body>
</html>
--------------030105070701090507020601--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Best way to extend XSD editor [message #597523 is a reply to message #61684] |
Mon, 06 February 2006 21:39 |
| Eclipse User |
|
|
|
Originally posted by: gennady_vanin-online.yahoo.com.br
Hello Dave,
I am eager to understand why have u moved from Castor to JAXB?
Correct me,
Guennadi Vanine
> Thanks for the quick reply.
>
> We've been using JAXB for quite some time. It's been working well for
> us as a Java/XML binding where the XML is governed by an XSD file. We
> started with Castor and moved to JAXB over time. Probably too much
> code to move to EMF.
>
> We're probably going to go with the external binding file approach.
> Tweaking the XSD to add annotations would cause many false updates (in
> our project re-release of a shared JAR file) just because an
> annotation was tweaked. So our model is similar to the metadata split
> between the base Ecore model metadata and the EMF code generator
> metadata.
>
> Dave
>
|
|
|
Powered by
FUDForum. Page generated in 0.02894 seconds
] 
Search
Help
Register
Login
Home
