Home » Modeling » UML2 » XMI datatype representation
|
| Re: XMI datatype representation [message #1003561 is a reply to message #1003440] |
Mon, 21 January 2013 14:16   |
 Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Claudio,
Pretty much the only thing you'll find at Eclipse that will produce and
consume XMI serializations is Ecore (equivalent to EMOF) and for that
you'd have to write code to convert your data value to a string and to
convert a string to the data value. In that code you'll have to solve
this problem.
This section of the specification looks ill conceived to me, like
someone thought it seemed like a good idea, but never stopped to
consider all the implications. E.g., what if x and y are multi-valued
properties? Maybe that's not allow for data types? Or your example
about how missing optional things are represented. Maybe they're
represented as an empty string, e.g., rect=",,2,5" verses rect="2,5,,"?
I wonder how one would escape a character if you need the value to use
something that's already defined to be the separator?
On 21/01/2013 9:49 AM, Claudio Persico wrote:
> Hi to everybody,
>
> On page 20 of the OMG XMI specs
> http://www.omg.org/spec/XMI/2.1.1/PDF/index.htm
>
> there's a paragraph called datatype representation.
>
> Referring to the example of the rectangle in the specification,
> suppose that two properties upperLeft and lowerRight were both [0..1]
> optional.
>
> If I have a string like
>
> <aRectangle rect="2,5" />
>
> How can I discriminate if "rect" refers to the upperLeft or to the
> lowerRight attribute?
>
> Thanks in advance,
>
> Claudio
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XMI datatype representation [message #1003564 is a reply to message #1003440] |
Mon, 21 January 2013 14:18 |
|
Hi, Claudio,
The first question would be how either corner of the rectangle could be
optional. A point isn't much of a rectangle. If a rectangle of zero
area is required, I would suggest that both points should be equal:
<aRectangle rect="2,5,2,5"/>
Then you won't have a representation problem. Otherwise, one has to be
practical. Something like this could help:
<aRectangle rect=",,4,7"/>
indicating a lower-right corner only (upper-left values are absent). Or even
<aRectangle rect=",4,7"/>
indicating the entire upper-left point being absent?
HTH,
Christian
On 2013-01-21 08:49:48 +0000, Claudio Persico said:
> Hi to everybody,
>
> On page 20 of the OMG XMI specs
> http://www.omg.org/spec/XMI/2.1.1/PDF/index.htm
>
> there's a paragraph called datatype representation.
>
> Referring to the example of the rectangle in the specification, suppose
> that two properties upperLeft and lowerRight were both [0..1] optional.
>
> If I have a string like
>
> <aRectangle rect="2,5" />
>
> How can I discriminate if "rect" refers to the upperLeft or to the
> lowerRight attribute?
>
> Thanks in advance,
>
> Claudio
|
|
|
| Re: XMI datatype representation [message #1003573 is a reply to message #1003564] |
Mon, 21 January 2013 14:37 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
On 21/01/2013 14:18, Christian W. Damus wrote:On 21/01/2013 14:18,
Christian W. Damus wrote:
> Hi, Claudio,
>
> Otherwise, one has to be practical. Something like this could help:
>
> <aRectangle rect=",,4,7"/>
Exactly.
Claudio: I think you are mis-reading the XSD. The attribute values are
optionally specified, not optionally serialized, so if the default
values are to be used, the commas must at least separate the
default/blank values.
Regards
Ed Willink
|
|
|
| Re: XMI datatype representation [message #1003581 is a reply to message #1003573] |
Mon, 21 January 2013 15:00 |
Claudio Persico
Messages: 24
Registered: November 2012 |
Junior Member |
|
|
Thanks to all of you for your replies,
Before make this post I thought an answer like
<aRectangle rect=",,4,7"/> as you suggested.
I made this trivial example only to explain the problem. But think what would happen using a profile like MARTE with several nested datatype, and added to those, other datatype made by myself.
You will agree with me that something like
<anObject obj=",,4,7,,0,5,4,,,,"/>
is something bad.
Again these strings must be written manually (but this is another problem).
Anyway writing the blank fields eliminate the advantage of having optional properties, according to me, because if it is optional and I don't have it in my model, I won't consder it at all.
Thank you,
Claudio
|
|
|
| Re: XMI datatype representation [message #1003596 is a reply to message #1003581] |
Mon, 21 January 2013 15:22 |
|
Hi, Claudio,
I agree with Ed Merks: the XMI spec for serialization of datatypes
seems not to have been thought out completely. The use of a single
separator character (as I understand from the spec, which could be my
mistake) just doesn't seem feasible for representation of nested data
structures, especially when multiplicities are involved.
Luckily, EMF provides a much more flexible approach: your EFactory
implementation can serialize datatypes any way you like. Never mind
XMI. You can go as far as using a JSON syntax if you like:
<aRectangle rect="{lowerRight={x='4',y='7'}}"/>
<aPolygon
vertices="[{x='0',y='0'},{x='4',y='2'},{x='2',y='4'},{x='-2',y='2'}]"/>
Cheers,
Christian
On 2013-01-21 15:00:39 +0000, Claudio Persico said:
> Thanks to all of you for your replies,
>
> Before make this post I thought an answer like
>
> <aRectangle rect=",,4,7"/> as you suggested.
>
> I made this trivial example only to explain the problem. But think what
> would happen using a profile like MARTE with several nested datatype,
> and added to those, other datatype made by myself.
>
> You will agree with me that something like
>
> <anObject obj=",,4,7,,0,5,4,,,,"/>
>
> is something bad.
>
> Again these strings must be written manually (but this is another problem).
>
> Anyway writing the blank fields eliminate the advantage of having
> optional properties, according to me, because if it is optional and I
> don't have it in my model, I won't consder it at all.
>
> Thank you,
>
> Claudio
|
|
|
Goto Forum:
Current Time: Sat Apr 20 16:30:34 GMT 2024
Powered by FUDForum. Page generated in 0.03784 seconds |
] 
Search
Help
Register
Login
Home
