Home » Modeling » EMF » XML Schema vs. XML Schema for XMI
| |
| Re: XML Schema vs. XML Schema for XMI [message #418779 is a reply to message #418774] |
Tue, 29 April 2008 13:50   |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Ed Merks wrote:
> You'll probably find I've ranted on this subject before. ... I
> would describe it as the most complex way to turn of validation that I
> could imagine. But if you are producing XMI serializations, that's
> pretty much the schema you'll need.
:-)
I'm doing this in the context of SOAP, where XML Schemas are used to define the
messages that will be exchanged (WSDL is the other part). Contrary to what I
believed some days ago, I don't think direct XMI serialization is suitable for
creating SOAP messages, although convenient. The main reason is how natural the
XML feels, which is important when the format is meant to be "open" and
"understandable", instead of just a practical technical encoding format.
I believe I can model both cases fairly well with Ecore, but one will be a
normal Ecore model (the XMI case), the other will be a model of the XML (the
standard XML Schema case).
Consider a phonebook case, where a Person contains PhoneNumbers. A service for
setting the mobile number of a Person can be modelled in two ways:
1) setPhoneNumber(Person person, PhoneNumber number)
2) setPhoneNumber(String personId, PhoneNumber number)
The first is natural from an Ecore perspective, and implicitly relies on XMI for
handling ID/IDREFs and hence is less XML-friendly. The second relies on an
explicit id and lookup as the mechanism for finding the correct Person object
(on the server) and more directly models the SOAP message XML that needs to be
constructed. A PhoneNumber will in both cases be thought of as a struct without
identity.
The advantage of using XML serialization instead of XMI serialization is that it
is easier to work with for non-XMI-based tools, like soapGUI and testing
tools. In addition, sometimes the XML Schema already exists, and the Ecore model
is "just" a more structured model of the data. The downside is that it requires
more manual work when modeling the operations and constructing the XML (I plan
to use Javascript and E4X as described in
http://www.ibm.com/developerworks/webservices/library/ws-aja x1/ for the latter).
Hallvard
|
|
|
| Re: XML Schema vs. XML Schema for XMI [message #418781 is a reply to message #418779] |
Tue, 29 April 2008 14:18 |
Ed Merks
Messages: 33146
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Ed Merks wrote:
>> You'll probably find I've ranted on this subject before. ... I would
>> describe it as the most complex way to turn of validation that I
>> could imagine. But if you are producing XMI serializations, that's
>> pretty much the schema you'll need.
>
> :-)
>
> I'm doing this in the context of SOAP, where XML Schemas are used to
> define the messages that will be exchanged (WSDL is the other part).
> Contrary to what I believed some days ago, I don't think direct XMI
> serialization is suitable for creating SOAP messages, although
> convenient. The main reason is how natural the XML feels, which is
> important when the format is meant to be "open" and "understandable",
> instead of just a practical technical encoding format.
>
> I believe I can model both cases fairly well with Ecore, but one will
> be a normal Ecore model (the XMI case), the other will be a model of
> the XML (the standard XML Schema case).
>
> Consider a phonebook case, where a Person contains PhoneNumbers. A
> service for setting the mobile number of a Person can be modelled in
> two ways:
> 1) setPhoneNumber(Person person, PhoneNumber number)
> 2) setPhoneNumber(String personId, PhoneNumber number)
> The first is natural from an Ecore perspective, and implicitly relies
> on XMI for handling ID/IDREFs and hence is less XML-friendly. The
> second relies on an explicit id and lookup as the mechanism for
> finding the correct Person object (on the server) and more directly
> models the SOAP message XML that needs to be constructed. A
> PhoneNumber will in both cases be thought of as a struct without
> identity.
It sound to me like you'd just want to model Person with an EAttribute
for which isID is true.
>
> The advantage of using XML serialization instead of XMI serialization
> is that it is easier to work with for non-XMI-based tools, like
> soapGUI and testing tools. In addition, sometimes the XML Schema
> already exists, and the Ecore model is "just" a more structured model
> of the data. The downside is that it requires more manual work when
> modeling the operations and constructing the XML (I plan to use
> Javascript and E4X as described in
> http://www.ibm.com/developerworks/webservices/library/ws-aja x1/ for
> the latter).
I'm not particularly fond of XMI serializations. You could just avoid
them. If you want a specific serialization format, you might take the
following approach. Export your model to an XML Schema, change that
schema to suit any serialization details you want, and then reimport
your Ecore mode from that XML Schema. Then be sure to use the generated
resource factory for serializing instances to respect that XML Schema...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XML Schema vs. XML Schema for XMI [message #418785 is a reply to message #418781] |
Tue, 29 April 2008 16:39 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Comments below.
Ed Merks wrote:
>> Consider a phonebook case, where a Person contains PhoneNumbers. A
>> service for setting the mobile number of a Person can be modelled in
>> two ways:
>> 1) setPhoneNumber(Person person, PhoneNumber number)
>> 2) setPhoneNumber(String personId, PhoneNumber number)
>> The first is natural from an Ecore perspective, and implicitly relies
>> on XMI for handling ID/IDREFs and hence is less XML-friendly. The
>> second relies on an explicit id and lookup as the mechanism for
>> finding the correct Person object (on the server) and more directly
>> models the SOAP message XML that needs to be constructed. A
>> PhoneNumber will in both cases be thought of as a struct without
>> identity.
> It sound to me like you'd just want to model Person with an EAttribute
> for which isID is true.
In this example, yes, but in general an object may have several attributes that
are used as keys relative to a parent. An id is just a special key where the
resource is the context for resolving it. E.g. PhoneNumber may be keyed with a
role attribute of type xsd:string relative to a Person. Hence, operations
referencing a PhoneNumber need a xsd:string role parameter.
> I'm not particularly fond of XMI serializations. You could just avoid
> them. If you want a specific serialization format, you might take the
> following approach. Export your model to an XML Schema, change that
> schema to suit any serialization details you want, and then reimport
> your Ecore mode from that XML Schema. Then be sure to use the generated
> resource factory for serializing instances to respect that XML Schema...
Thank you for this suggestion! Currently, I'm avoiding code generation due to
deployment issues, but I guess your point is to make sure to use the correct
Resource implementation and code for setting load options etc.
Hallvard
|
|
|
Goto Forum:
Current Time: Fri May 10 13:51:14 GMT 2024
Powered by FUDForum. Page generated in 0.04082 seconds |
] 
Search
Help
Register
Login
Home
