Home » Modeling » EMF » Rules for XMI serialization
|
| Re: Rules for XMI serialization [message #1385654 is a reply to message #1385629] |
Tue, 10 June 2014 09:11   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Marc-Florian
I think that you will find that XMI.xsd is just a redistribution of an
OMG file to terminate otherwise dangling references.
IIRC the EMF book does a reasonable job of defining the XSD behaviour and
http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
fills in many of the gaps.
I'm guessing that you're more interested in UML/SysML for the TIWG so
asking on the EMF newsgroup may be the wrong place.
Unfortunately, I've yet to find any documentation on the EAnnotations
that are used for UML subsets/union/redefines that I suspect you will
find essential.
However if you get your metalevel abstract enough maybe serialized
subsets can go away.
EMF is very flexible in its treatment of xmi:id, providing a verbose
form out of the box that is intolerant of manual edits. You can easily
substitute your own. This would be orthogonal to the semantic GUOID
under discussion by TIWG. Adding support for serializing an xmi:guoid
wouldn't be that hard.
Of course you could just look at it the other way.
Create a UML file with interesting constructs and see whether the *.uml
file seems sensible.
But IMHO, UML serialization cannot be sensible today, since UML
neglected to model a StereotypeInstance, instead choosing to rely on MOF
jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
has a base_XXX reference terminated in an embedded versioned Ecore
equivalent of the UML profile. Surely MOFFOL should be useable?
Again IMHO, if everything is sensibly modelled, serialization becomes
regular and easy. Conversely if inadequate modeling is resolved by the
serialization you have to have complex non-standard inadequate and
determinedly buggy serializers.
Regards
Ed Willink
On 10/06/2014 08:33, Marc-Florian Wendland wrote:
> Dear all,
>
> I am involved in a standardization activity that develops a MOF-based
> language; a crucial part of this standard for interoperability is the
> unambiguous specification of an exchange format. The group agreed that
> this exchange format will be XMI, or more precisely EMF XMI. Since XMI
> has many alternatives in its rules I was wondering whether there is a
> document out there that describes the production rules or constraints
> of EMF XMI. I would need that information to describe the exchange
> format of the standard.
>
> I already found the XMI.xsd in the Ecore implementation, but it is
> kind of error prone to infer the production rules just by browsing
> through the schema rules. Kind of a EMF XMI specification that
> describes or highlights its relation to the general XMI standard would
> definitely help.
>
> Best regards,
> Marc-Florian
|
|
|
| Re: Rules for XMI serialization [message #1385658 is a reply to message #1385654] |
Tue, 10 June 2014 09:53 |
Marc-Florian Wendland
Messages: 83
Registered: January 2013 |
Member |
|
|
Hi Ed,
thanks, for your immediate response, but it has nothing to do whatsoever
with UML or OMG. It is in the context of ETSI. We need a canonical XMI
schema for the language that is going to be invented (not to be confused
with OMG canonical XMI). It is not the question whether someting is sensibly
modeled or not, but a mere requirement for model exchange.
AS I said, the XMI standard provides many alternative ways to serialize its
content; I am pretty sure EMF does not support all these alternatives (how
could it?), but resolves these alternatives. Since we decided that the EMF
rules for XMI serialization are sufficient and working, we need a
specification of the EMF schema and document prodcution rules, so that tool
vendors (outside EMF) can implement the serialization and deserialization
properly. And of course to track changes properly if something has changed
in the EMF XMI serialization rules.
Btw, IIRC -> what does this mean? ;-)
Best regards,
Marc-Florian
"Ed Willink" wrote in message news:ln6i3k$vvs$1@xxxxxxxxe.org...
Hi Marc-Florian
I think that you will find that XMI.xsd is just a redistribution of an
OMG file to terminate otherwise dangling references.
IIRC the EMF book does a reasonable job of defining the XSD behaviour and
http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
fills in many of the gaps.
I'm guessing that you're more interested in UML/SysML for the TIWG so
asking on the EMF newsgroup may be the wrong place.
Unfortunately, I've yet to find any documentation on the EAnnotations
that are used for UML subsets/union/redefines that I suspect you will
find essential.
However if you get your metalevel abstract enough maybe serialized
subsets can go away.
EMF is very flexible in its treatment of xmi:id, providing a verbose
form out of the box that is intolerant of manual edits. You can easily
substitute your own. This would be orthogonal to the semantic GUOID
under discussion by TIWG. Adding support for serializing an xmi:guoid
wouldn't be that hard.
Of course you could just look at it the other way.
Create a UML file with interesting constructs and see whether the *.uml
file seems sensible.
But IMHO, UML serialization cannot be sensible today, since UML
neglected to model a StereotypeInstance, instead choosing to rely on MOF
jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
has a base_XXX reference terminated in an embedded versioned Ecore
equivalent of the UML profile. Surely MOFFOL should be useable?
Again IMHO, if everything is sensibly modelled, serialization becomes
regular and easy. Conversely if inadequate modeling is resolved by the
serialization you have to have complex non-standard inadequate and
determinedly buggy serializers.
Regards
Ed Willink
On 10/06/2014 08:33, Marc-Florian Wendland wrote:
> Dear all,
>
> I am involved in a standardization activity that develops a MOF-based
> language; a crucial part of this standard for interoperability is the
> unambiguous specification of an exchange format. The group agreed that
> this exchange format will be XMI, or more precisely EMF XMI. Since XMI has
> many alternatives in its rules I was wondering whether there is a document
> out there that describes the production rules or constraints of EMF XMI. I
> would need that information to describe the exchange format of the
> standard.
>
> I already found the XMI.xsd in the Ecore implementation, but it is kind of
> error prone to infer the production rules just by browsing through the
> schema rules. Kind of a EMF XMI specification that describes or highlights
> its relation to the general XMI standard would definitely help.
>
> Best regards,
> Marc-Florian
|
|
|
| Re: Rules for XMI serialization [message #1385666 is a reply to message #1385658] |
Tue, 10 June 2014 11:06 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
HI
IIRC => If I Recall Correctly
Seems like EMF is good for you without any UML difficulties, but you
might want to look at canonical XMI to see if it defines a better xmi:id
allocation algorithm.
The real challenge is if you want to allow evolution of your spec to
refactor the metamodel in ways that break simple xmi:id allocation
algorithms. If so, you need to allocate xmi:ids on the basis of semantic
stability rather than structural hierarchy, and do so before anyone
writes a model to model transformation using your metamodel.
At first sight such evolution is obviously bad. But just consider UML.
We know that semantically the differences between a UML 2.0 and 2.5
Class are trivial so we would like them to have the same 'xmi:id' within
different nsURIs. Conversely in Ecore, the problem is side-stepped by
pretending that nothing has changed since 2002; still
http://www.eclipse.org/emf/2002/Ecore even though many good things, in
particular EGenericType, have happened in the meantime. For new ETSI
specifications you could ignore the problem, but your successors will
thank you if you try to learn from UML.
I suggest an xmi:id allocator that uses values that are persisted within
the model; i.e. your root metamodel Element has an xmiID field. TIWG is
considering doing this by applying an identity stereotype to everything.
Regards
Ed
On 10/06/2014 10:53, Marc-Florian Wendland wrote:
> Hi Ed,
>
> thanks, for your immediate response, but it has nothing to do
> whatsoever with UML or OMG. It is in the context of ETSI. We need a
> canonical XMI schema for the language that is going to be invented
> (not to be confused with OMG canonical XMI). It is not the question
> whether someting is sensibly modeled or not, but a mere requirement
> for model exchange.
>
> AS I said, the XMI standard provides many alternative ways to
> serialize its content; I am pretty sure EMF does not support all these
> alternatives (how could it?), but resolves these alternatives. Since
> we decided that the EMF rules for XMI serialization are sufficient and
> working, we need a specification of the EMF schema and document
> prodcution rules, so that tool vendors (outside EMF) can implement the
> serialization and deserialization properly. And of course to track
> changes properly if something has changed in the EMF XMI serialization
> rules.
>
> Btw, IIRC -> what does this mean? ;-)
>
>
> Best regards,
> Marc-Florian
>
> "Ed Willink" wrote in message news:ln6i3k$vvs$1@xxxxxxxxe.org...
>
> Hi Marc-Florian
>
> I think that you will find that XMI.xsd is just a redistribution of an
> OMG file to terminate otherwise dangling references.
>
> IIRC the EMF book does a reasonable job of defining the XSD behaviour and
> http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
>
> fills in many of the gaps.
>
> I'm guessing that you're more interested in UML/SysML for the TIWG so
> asking on the EMF newsgroup may be the wrong place.
>
> Unfortunately, I've yet to find any documentation on the EAnnotations
> that are used for UML subsets/union/redefines that I suspect you will
> find essential.
>
> However if you get your metalevel abstract enough maybe serialized
> subsets can go away.
>
> EMF is very flexible in its treatment of xmi:id, providing a verbose
> form out of the box that is intolerant of manual edits. You can easily
> substitute your own. This would be orthogonal to the semantic GUOID
> under discussion by TIWG. Adding support for serializing an xmi:guoid
> wouldn't be that hard.
>
> Of course you could just look at it the other way.
>
> Create a UML file with interesting constructs and see whether the *.uml
> file seems sensible.
>
> But IMHO, UML serialization cannot be sensible today, since UML
> neglected to model a StereotypeInstance, instead choosing to rely on MOF
> jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
> has a base_XXX reference terminated in an embedded versioned Ecore
> equivalent of the UML profile. Surely MOFFOL should be useable?
>
> Again IMHO, if everything is sensibly modelled, serialization becomes
> regular and easy. Conversely if inadequate modeling is resolved by the
> serialization you have to have complex non-standard inadequate and
> determinedly buggy serializers.
>
> Regards
>
> Ed Willink
>
> On 10/06/2014 08:33, Marc-Florian Wendland wrote:
>> Dear all,
>>
>> I am involved in a standardization activity that develops a MOF-based
>> language; a crucial part of this standard for interoperability is the
>> unambiguous specification of an exchange format. The group agreed
>> that this exchange format will be XMI, or more precisely EMF XMI.
>> Since XMI has many alternatives in its rules I was wondering whether
>> there is a document out there that describes the production rules or
>> constraints of EMF XMI. I would need that information to describe the
>> exchange format of the standard.
>>
>> I already found the XMI.xsd in the Ecore implementation, but it is
>> kind of error prone to infer the production rules just by browsing
>> through the schema rules. Kind of a EMF XMI specification that
>> describes or highlights its relation to the general XMI standard
>> would definitely help.
>>
>> Best regards,
>> Marc-Florian
>
|
|
|
| Re: Rules for XMI serialization [message #1385759 is a reply to message #1385658] |
Wed, 11 June 2014 05:27 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Marc-Florian,
Comments below.
On 10/06/2014 11:53 AM, Marc-Florian Wendland wrote:
> Hi Ed,
>
> thanks, for your immediate response, but it has nothing to do
> whatsoever with UML or OMG. It is in the context of ETSI. We need a
> canonical XMI schema for the language that is going to be invented
> (not to be confused with OMG canonical XMI).
I don't know what a canonical XMI Schema ought to look like, but
anything in the form of an XML Schema is bound to be nonsense and
useless for any practical purpose.
> It is not the question whether someting is sensibly modeled or not,
> but a mere requirement for model exchange.
The model itself is the canonical definition. It must be well
understood by the producer and the consumer.
>
> AS I said, the XMI standard provides many alternative ways to
> serialize its content;
Indeed, it's generally the case that many things could be serialized as
an element or attribute.
> I am pretty sure EMF does not support all these alternatives (how
> could it?), but resolves these alternatives.
EMF generally doesn't care if it's an element or an attribute, but uses
either to map to the name of a structural feature. EMF also extends XMI
by allowing cross references to be serialized as an attribute
(OPTION_ENCODED_ATTRIBUTE_STYLE), where it uses logical pairs, either an
optional QName and a URI with fragment, or an ID where one call tell
what's what by the presence of a :, #, or lack of either.
> Since we decided that the EMF rules for XMI serialization are
> sufficient and working, we need a specification of the EMF schema and
> document prodcution rules, so that tool vendors (outside EMF) can
> implement the serialization and deserialization properly.
You can't generally describe the serialization with an XML Schema. You
can define/describe the rules, but not reasonably with an XML Schema.
> And of course to track changes properly if something has changed in
> the EMF XMI serialization rules.
If you can avoid multiple inheritance in your model, you can use
extended metadata annotations to strictly control the serialization and
from that derive the corresponding XML Schema. But if you intend to
serialize as XMI, any consumer will need to know the Ecore/EMOF model
and will need to be able to parse XMI...
>
> Btw, IIRC -> what does this mean? ;-)
>
>
> Best regards,
> Marc-Florian
>
> "Ed Willink" wrote in message news:ln6i3k$vvs$1@xxxxxxxxe.org...
>
> Hi Marc-Florian
>
> I think that you will find that XMI.xsd is just a redistribution of an
> OMG file to terminate otherwise dangling references.
>
> IIRC the EMF book does a reasonable job of defining the XSD behaviour and
> http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
>
> fills in many of the gaps.
>
> I'm guessing that you're more interested in UML/SysML for the TIWG so
> asking on the EMF newsgroup may be the wrong place.
>
> Unfortunately, I've yet to find any documentation on the EAnnotations
> that are used for UML subsets/union/redefines that I suspect you will
> find essential.
>
> However if you get your metalevel abstract enough maybe serialized
> subsets can go away.
>
> EMF is very flexible in its treatment of xmi:id, providing a verbose
> form out of the box that is intolerant of manual edits. You can easily
> substitute your own. This would be orthogonal to the semantic GUOID
> under discussion by TIWG. Adding support for serializing an xmi:guoid
> wouldn't be that hard.
>
> Of course you could just look at it the other way.
>
> Create a UML file with interesting constructs and see whether the *.uml
> file seems sensible.
>
> But IMHO, UML serialization cannot be sensible today, since UML
> neglected to model a StereotypeInstance, instead choosing to rely on MOF
> jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
> has a base_XXX reference terminated in an embedded versioned Ecore
> equivalent of the UML profile. Surely MOFFOL should be useable?
>
> Again IMHO, if everything is sensibly modelled, serialization becomes
> regular and easy. Conversely if inadequate modeling is resolved by the
> serialization you have to have complex non-standard inadequate and
> determinedly buggy serializers.
>
> Regards
>
> Ed Willink
>
> On 10/06/2014 08:33, Marc-Florian Wendland wrote:
>> Dear all,
>>
>> I am involved in a standardization activity that develops a MOF-based
>> language; a crucial part of this standard for interoperability is the
>> unambiguous specification of an exchange format. The group agreed
>> that this exchange format will be XMI, or more precisely EMF XMI.
>> Since XMI has many alternatives in its rules I was wondering whether
>> there is a document out there that describes the production rules or
>> constraints of EMF XMI. I would need that information to describe the
>> exchange format of the standard.
>>
>> I already found the XMI.xsd in the Ecore implementation, but it is
>> kind of error prone to infer the production rules just by browsing
>> through the schema rules. Kind of a EMF XMI specification that
>> describes or highlights its relation to the general XMI standard
>> would definitely help.
>>
>> Best regards,
>> Marc-Florian
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Rules for XMI serialization [message #1385870 is a reply to message #1385759] |
Wed, 11 June 2014 20:24 |
Marc-Florian Wendland
Messages: 83
Registered: January 2013 |
Member |
|
|
Hi Ed,
thanks for your comments. You may already have noticed that I am not an XMI
expert, however, I am really wondering what all these XMI Schema production
rules in the spec are for if, as you stated, anything in the form of an XML
Schema is bound to be nonsense.
It is possible to export an Ecore model as XML Schema for XMI. Why is this
nonsense? Doesn't it describe the way how XMI documents are allowed to look
like? Wouldn't it be possible for vendors to use this XML Schema for XMI to
check whether XMI documents conform to the Schema?
>The model itself is the canonical definition. It must be well understood
>by the producer and the consumer.
What is the 'model itself'? You mean the metamodel?
>You can't generally describe the serialization with an XML Schema. You can
>define/describe the rules, but not reasonably with an XML Schema.
Well, maybe bad wording. I can describe the structure XMI documents have to
abide by and the rules how to serialize the content of attributes and
elements in a textual manner, right?
Thanks again for help.
Regards,
Marc-Florian
"Ed Merks" wrote in message news:ln8pbs$nfm$1@xxxxxxxxe.org...
Marc-Florian,
Comments below.
On 10/06/2014 11:53 AM, Marc-Florian Wendland wrote:
> Hi Ed,
>
> thanks, for your immediate response, but it has nothing to do whatsoever
> with UML or OMG. It is in the context of ETSI. We need a canonical XMI
> schema for the language that is going to be invented (not to be confused
> with OMG canonical XMI).
I don't know what a canonical XMI Schema ought to look like, but
anything in the form of an XML Schema is bound to be nonsense and
useless for any practical purpose.
> It is not the question whether someting is sensibly modeled or not, but a
> mere requirement for model exchange.
The model itself is the canonical definition. It must be well
understood by the producer and the consumer.
>
> AS I said, the XMI standard provides many alternative ways to serialize
> its content;
Indeed, it's generally the case that many things could be serialized as
an element or attribute.
> I am pretty sure EMF does not support all these alternatives (how could
> it?), but resolves these alternatives.
EMF generally doesn't care if it's an element or an attribute, but uses
either to map to the name of a structural feature. EMF also extends XMI
by allowing cross references to be serialized as an attribute
(OPTION_ENCODED_ATTRIBUTE_STYLE), where it uses logical pairs, either an
optional QName and a URI with fragment, or an ID where one call tell
what's what by the presence of a :, #, or lack of either.
> Since we decided that the EMF rules for XMI serialization are sufficient
> and working, we need a specification of the EMF schema and document
> prodcution rules, so that tool vendors (outside EMF) can implement the
> serialization and deserialization properly.
You can't generally describe the serialization with an XML Schema. You
can define/describe the rules, but not reasonably with an XML Schema.
> And of course to track changes properly if something has changed in the
> EMF XMI serialization rules.
If you can avoid multiple inheritance in your model, you can use
extended metadata annotations to strictly control the serialization and
from that derive the corresponding XML Schema. But if you intend to
serialize as XMI, any consumer will need to know the Ecore/EMOF model
and will need to be able to parse XMI...
>
> Btw, IIRC -> what does this mean? ;-)
>
>
> Best regards,
> Marc-Florian
>
> "Ed Willink" wrote in message news:ln6i3k$vvs$1@xxxxxxxxe.org...
>
> Hi Marc-Florian
>
> I think that you will find that XMI.xsd is just a redistribution of an
> OMG file to terminate otherwise dangling references.
>
> IIRC the EMF book does a reasonable job of defining the XSD behaviour and
> http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
> fills in many of the gaps.
>
> I'm guessing that you're more interested in UML/SysML for the TIWG so
> asking on the EMF newsgroup may be the wrong place.
>
> Unfortunately, I've yet to find any documentation on the EAnnotations
> that are used for UML subsets/union/redefines that I suspect you will
> find essential.
>
> However if you get your metalevel abstract enough maybe serialized
> subsets can go away.
>
> EMF is very flexible in its treatment of xmi:id, providing a verbose
> form out of the box that is intolerant of manual edits. You can easily
> substitute your own. This would be orthogonal to the semantic GUOID
> under discussion by TIWG. Adding support for serializing an xmi:guoid
> wouldn't be that hard.
>
> Of course you could just look at it the other way.
>
> Create a UML file with interesting constructs and see whether the *.uml
> file seems sensible.
>
> But IMHO, UML serialization cannot be sensible today, since UML
> neglected to model a StereotypeInstance, instead choosing to rely on MOF
> jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
> has a base_XXX reference terminated in an embedded versioned Ecore
> equivalent of the UML profile. Surely MOFFOL should be useable?
>
> Again IMHO, if everything is sensibly modelled, serialization becomes
> regular and easy. Conversely if inadequate modeling is resolved by the
> serialization you have to have complex non-standard inadequate and
> determinedly buggy serializers.
>
> Regards
>
> Ed Willink
>
> On 10/06/2014 08:33, Marc-Florian Wendland wrote:
>> Dear all,
>>
>> I am involved in a standardization activity that develops a MOF-based
>> language; a crucial part of this standard for interoperability is the
>> unambiguous specification of an exchange format. The group agreed that
>> this exchange format will be XMI, or more precisely EMF XMI. Since XMI
>> has many alternatives in its rules I was wondering whether there is a
>> document out there that describes the production rules or constraints of
>> EMF XMI. I would need that information to describe the exchange format of
>> the standard.
>>
>> I already found the XMI.xsd in the Ecore implementation, but it is kind
>> of error prone to infer the production rules just by browsing through the
>> schema rules. Kind of a EMF XMI specification that describes or
>> highlights its relation to the general XMI standard would definitely
>> help.
>>
>> Best regards,
>> Marc-Florian
>
|
|
|
| Re: Rules for XMI serialization [message #1385878 is a reply to message #1385870] |
Wed, 11 June 2014 22:31 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Marc-Florian,
Comments below.
On 11/06/2014 10:24 PM, Marc-Florian Wendland wrote:
> Hi Ed,
>
> thanks for your comments. You may already have noticed that I am not
> an XMI expert, however, I am really wondering what all these XMI
> Schema production rules in the spec are for if, as you stated,
> anything in the form of an XML Schema is bound to be nonsense.
Best ask the OMG what they're for.
>
> It is possible to export an Ecore model as XML Schema for XMI. Why is
> this nonsense?
Because, if you look closely, you'll see it's a complex way of turning
off schema validation.
> Doesn't it describe the way how XMI documents are allowed to look like?
In theory, but in practice, it's so loose, that it provides no
reasonable constraints.
> Wouldn't it be possible for vendors to use this XML Schema for XMI to
> check whether XMI documents conform to the Schema?
Yes, but unfortunately all too many ill formed documents would deemed valid.
>
>> The model itself is the canonical definition. It must be well
>> understood by the producer and the consumer.
>
> What is the 'model itself'? You mean the metamodel?
What's the difference between a model and a metamodel?
>
>> You can't generally describe the serialization with an XML Schema.
>> You can define/describe the rules, but not reasonably with an XML
>> Schema.
>
> Well, maybe bad wording. I can describe the structure XMI documents
> have to abide by and the rules how to serialize the content of
> attributes and elements in a textual manner, right?
Yes, but doing so with an XML Schema isn't going to suffice, in general.
>
> Thanks again for help.
>
> Regards,
> Marc-Florian
>
> "Ed Merks" wrote in message news:ln8pbs$nfm$1@xxxxxxxxe.org...
>
> Marc-Florian,
>
> Comments below.
>
> On 10/06/2014 11:53 AM, Marc-Florian Wendland wrote:
>> Hi Ed,
>>
>> thanks, for your immediate response, but it has nothing to do
>> whatsoever with UML or OMG. It is in the context of ETSI. We need a
>> canonical XMI schema for the language that is going to be invented
>> (not to be confused with OMG canonical XMI).
> I don't know what a canonical XMI Schema ought to look like, but
> anything in the form of an XML Schema is bound to be nonsense and
> useless for any practical purpose.
>> It is not the question whether someting is sensibly modeled or not,
>> but a mere requirement for model exchange.
> The model itself is the canonical definition. It must be well
> understood by the producer and the consumer.
>>
>> AS I said, the XMI standard provides many alternative ways to
>> serialize its content;
> Indeed, it's generally the case that many things could be serialized as
> an element or attribute.
>> I am pretty sure EMF does not support all these alternatives (how
>> could it?), but resolves these alternatives.
> EMF generally doesn't care if it's an element or an attribute, but uses
> either to map to the name of a structural feature. EMF also extends XMI
> by allowing cross references to be serialized as an attribute
> (OPTION_ENCODED_ATTRIBUTE_STYLE), where it uses logical pairs, either an
> optional QName and a URI with fragment, or an ID where one call tell
> what's what by the presence of a :, #, or lack of either.
>> Since we decided that the EMF rules for XMI serialization are
>> sufficient and working, we need a specification of the EMF schema and
>> document prodcution rules, so that tool vendors (outside EMF) can
>> implement the serialization and deserialization properly.
> You can't generally describe the serialization with an XML Schema. You
> can define/describe the rules, but not reasonably with an XML Schema.
>> And of course to track changes properly if something has changed in
>> the EMF XMI serialization rules.
> If you can avoid multiple inheritance in your model, you can use
> extended metadata annotations to strictly control the serialization and
> from that derive the corresponding XML Schema. But if you intend to
> serialize as XMI, any consumer will need to know the Ecore/EMOF model
> and will need to be able to parse XMI...
>>
>> Btw, IIRC -> what does this mean? ;-)
>>
>>
>> Best regards,
>> Marc-Florian
>>
>> "Ed Willink" wrote in message news:ln6i3k$vvs$1@xxxxxxxxe.org...
>>
>> Hi Marc-Florian
>>
>> I think that you will find that XMI.xsd is just a redistribution of an
>> OMG file to terminate otherwise dangling references.
>>
>> IIRC the EMF book does a reasonable job of defining the XSD behaviour
>> and
>> http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf
>>
>> fills in many of the gaps.
>>
>> I'm guessing that you're more interested in UML/SysML for the TIWG so
>> asking on the EMF newsgroup may be the wrong place.
>>
>> Unfortunately, I've yet to find any documentation on the EAnnotations
>> that are used for UML subsets/union/redefines that I suspect you will
>> find essential.
>>
>> However if you get your metalevel abstract enough maybe serialized
>> subsets can go away.
>>
>> EMF is very flexible in its treatment of xmi:id, providing a verbose
>> form out of the box that is intolerant of manual edits. You can easily
>> substitute your own. This would be orthogonal to the semantic GUOID
>> under discussion by TIWG. Adding support for serializing an xmi:guoid
>> wouldn't be that hard.
>>
>> Of course you could just look at it the other way.
>>
>> Create a UML file with interesting constructs and see whether the *.uml
>> file seems sensible.
>>
>> But IMHO, UML serialization cannot be sensible today, since UML
>> neglected to model a StereotypeInstance, instead choosing to rely on MOF
>> jiggery-pokery. In Eclipse UML, this means that the StereotypeInstance
>> has a base_XXX reference terminated in an embedded versioned Ecore
>> equivalent of the UML profile. Surely MOFFOL should be useable?
>>
>> Again IMHO, if everything is sensibly modelled, serialization becomes
>> regular and easy. Conversely if inadequate modeling is resolved by the
>> serialization you have to have complex non-standard inadequate and
>> determinedly buggy serializers.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 10/06/2014 08:33, Marc-Florian Wendland wrote:
>>> Dear all,
>>>
>>> I am involved in a standardization activity that develops a
>>> MOF-based language; a crucial part of this standard for
>>> interoperability is the unambiguous specification of an exchange
>>> format. The group agreed that this exchange format will be XMI, or
>>> more precisely EMF XMI. Since XMI has many alternatives in its rules
>>> I was wondering whether there is a document out there that describes
>>> the production rules or constraints of EMF XMI. I would need that
>>> information to describe the exchange format of the standard.
>>>
>>> I already found the XMI.xsd in the Ecore implementation, but it is
>>> kind of error prone to infer the production rules just by browsing
>>> through the schema rules. Kind of a EMF XMI specification that
>>> describes or highlights its relation to the general XMI standard
>>> would definitely help.
>>>
>>> Best regards,
>>> Marc-Florian
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 05:38:32 GMT 2024
Powered by FUDForum. Page generated in 0.02456 seconds |
] 
Search
Help
Register
Login
Home
