Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ecore vs XML
Ecore vs XML [message #420821] Fri, 11 July 2008 10:15 Go to next message
Yann is currently offline YannFriend
Messages: 1
Registered: July 2009
Junior Member
Hi,

I was wondering what are the advantages of using Ecore to make Domain
Specific Languages rather than using XML. I find the xmi syntax for the
models really complicated. It's true most of the time you don't have to
write xmi by yourself, but there's still moments where you need to.
Several times I have spent a few hours solving a xmi related bug in my
models.
Re: Ecore vs XML [message #420828 is a reply to message #420821] Fri, 11 July 2008 13:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33139
Registered: July 2009
Senior Member
Yann,

EMF supports importing an XML Schema to convert it to Ecore and in that
case, instances will be serialized according to originating XML Schema.
This is done by recording extending meta data annotations on the Ecore
model itself, so even if you don't start with a schema, you can tailor
the XML serialization the same way as if you were using XML Schema to
define your model. There really isn't all that much difference between
an XMI serialization and a "XML" serialization and in any case, XML is
only marginally human readable in the first place, so doesn't seem even
close to ideal for defining a DSL. XML Schema has little ability to
express typed references---IDREF and anyURI are both untyped in terms of
what's being referenced, so it's really not expressive enough to fully
define a DSL. The oAW/itemis folks are doing cool stuff to support
proper human readable notations for any model.

It would be really sad to have to write XMI or XML for that matter by
hand...


Yann wrote:
> Hi,
>
> I was wondering what are the advantages of using Ecore to make Domain
> Specific Languages rather than using XML. I find the xmi syntax for
> the models really complicated. It's true most of the time you don't
> have to write xmi by yourself, but there's still moments where you
> need to. Several times I have spent a few hours solving a xmi related
> bug in my models.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Ecore vs XML [message #420834 is a reply to message #420828] Fri, 11 July 2008 18:03 Go to previous messageGo to next message
yann is currently offline yannFriend
Messages: 1
Registered: July 2009
Junior Member
I agree that XML is not the best language to write and read directly. If
programming languages like Java used a XML-based syntax, it would be a
chore (actually a bit like xslt is right now). So I agree that languages
with a grammar-based syntax are better. But I think for some purposes,
like (X)HTML, XML is not so bad. With an IDE that provides completion
it's faster than using a graphical editor. So I see a huge gap between
writing a model in XML, which is not optimal but easy and fast with a
bit of completion, and writing a model in a
xmi-serialized-conformed-to-ecore form, which is hard and slow (and even
if you don't write that directly there are times when you have to see
how things work closer to the metal).

Another thing that bugs me is that even if XML is "really not expressive
enough to fully define a DSL", I see a lot of DSL everywhere in XML
(HTML, RSS, JSF, Hibernate, Spring, MathML, there are thousands of them.
And on the EMF side I see UML2 and 5 other models from the MDT project
and that's all.

Ed Merks wrote :
> Yann,
>
> EMF supports importing an XML Schema to convert it to Ecore and in that
> case, instances will be serialized according to originating XML Schema.
> This is done by recording extending meta data annotations on the Ecore
> model itself, so even if you don't start with a schema, you can tailor
> the XML serialization the same way as if you were using XML Schema to
> define your model. There really isn't all that much difference between
> an XMI serialization and a "XML" serialization and in any case, XML is
> only marginally human readable in the first place, so doesn't seem even
> close to ideal for defining a DSL. XML Schema has little ability to
> express typed references---IDREF and anyURI are both untyped in terms of
> what's being referenced, so it's really not expressive enough to fully
> define a DSL. The oAW/itemis folks are doing cool stuff to support
> proper human readable notations for any model.
>
> It would be really sad to have to write XMI or XML for that matter by
> hand...
>
>
> Yann wrote:
>> Hi,
>>
>> I was wondering what are the advantages of using Ecore to make Domain
>> Specific Languages rather than using XML. I find the xmi syntax for
>> the models really complicated. It's true most of the time you don't
>> have to write xmi by yourself, but there's still moments where you
>> need to. Several times I have spent a few hours solving a xmi related
>> bug in my models.
Re: Ecore vs XML [message #420835 is a reply to message #420834] Fri, 11 July 2008 19:08 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33139
Registered: July 2009
Senior Member
Yann,

Comments below.

yann wrote:
> I agree that XML is not the best language to write and read directly.
It makes you wonder why it's become such a panacea... I would speculate
it's so that developers can avoid writing parsers.
> If programming languages like Java used a XML-based syntax, it would
> be a chore (actually a bit like xslt is right now).
It's to gross to even imagine without feeling sick.
> So I agree that languages with a grammar-based syntax are better. But
> I think for some purposes, like (X)HTML, XML is not so bad.
Yes, in any scenario where the user can be presented with a human
readable for and the XML is "just" a serialization they don't need to
see, it's not a bad thing.
> With an IDE that provides completion it's faster than using a
> graphical editor.
Certainly, but a WYSIWYG editor is what most people prefer over editing
raw HTML.
> So I see a huge gap between writing a model in XML, which is not
> optimal but easy and fast with a bit of completion, and writing a
> model in a xmi-serialized-conformed-to-ecore form, which is hard and
> slow (and even if you don't write that directly there are times when
> you have to see how things work closer to the metal).
I see the difference between XMI and XML as a very narrow one. After
all there's XMIResourceImpl and XMLResourceImpl so using XMI is your own
personal choice, not something EMF dictates. If you delete the XMI
namespace and version attribute, there's only the XML left. Other than
the "href" thing, there's really no significant difference...
>
> Another thing that bugs me is that even if XML is "really not
> expressive enough to fully define a DSL", I see a lot of DSL
> everywhere in XML (HTML, RSS, JSF, Hibernate, Spring, MathML, there
> are thousands of them. And on the EMF side I see UML2 and 5 other
> models from the MDT project and that's all.
You've just not looked around all that much. Have a look at GMF, WTP,
DTP, STP, OHF, Tigerstripe, VE, TPTP,and so on. And consider that if
you define DSL as something defined with a model and you consider XML
Schema a model, then there's an EMF model for all those XML syntaxes.
But stop and consider XML Schema itself for a moment. If all you had to
represent it was DOM, you'd be kind of screwed wouldn't you? You'd just
have a low level syntactic representation and no infrastructure to
resolve QName, handle imports, or anything else. And that's what I mean
about XML Schema itself not being sufficiently powerful to define a rich
DSL. The XML Schema for schemas might be find for validated if an XML
instance conforms to the schema for schemas, but it doesn't do much good
for defining what one of those instances means; you need XSD.ecore for that.

Even if you believe XML Schema is sufficiently powerful for most of your
needs, I'm sure editing DOM isn't going to turn your crank nor that of
your users...
>
>
> Ed Merks wrote :
>> Yann,
>>
>> EMF supports importing an XML Schema to convert it to Ecore and in
>> that case, instances will be serialized according to originating XML
>> Schema. This is done by recording extending meta data annotations on
>> the Ecore model itself, so even if you don't start with a schema, you
>> can tailor the XML serialization the same way as if you were using
>> XML Schema to define your model. There really isn't all that much
>> difference between an XMI serialization and a "XML" serialization and
>> in any case, XML is only marginally human readable in the first
>> place, so doesn't seem even close to ideal for defining a DSL. XML
>> Schema has little ability to express typed references---IDREF and
>> anyURI are both untyped in terms of what's being referenced, so it's
>> really not expressive enough to fully define a DSL. The oAW/itemis
>> folks are doing cool stuff to support proper human readable notations
>> for any model.
>>
>> It would be really sad to have to write XMI or XML for that matter by
>> hand...
>>
>>
>> Yann wrote:
>>> Hi,
>>>
>>> I was wondering what are the advantages of using Ecore to make
>>> Domain Specific Languages rather than using XML. I find the xmi
>>> syntax for the models really complicated. It's true most of the time
>>> you don't have to write xmi by yourself, but there's still moments
>>> where you need to. Several times I have spent a few hours solving a
>>> xmi related bug in my models.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:in memory XML representation
Next Topic:Renaming a feature in XMI serialization
Goto Forum:
  


Current Time: Tue Apr 23 07:15:53 GMT 2024

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

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

Back to the top