Eclipse Community Forums: UML2 » navigable owned end property vs. owned end property

Help

Home

Home » Modeling » UML2 » navigable owned end property vs. owned end property

Show: Today's Messages :: Show Polls :: Message Navigator

navigable owned end property vs. owned end property [message #474990]

Tue, 07 August 2007 20:24

Manar El-Kady

Messages: 78
Registered: July 2009

Member

Hi,

I'd like to ask about the difference between the navigable owned end
property and the owned end property for the association?
The navigable end property is usually owned by the class on the opposite
side of the association, and the non-navigable end property is owned by
the association itself. So, what is the need for the navigable owned end
property for the association?

Thanks in advance,

Manar

Report message to a moderator

Re: navigable owned end property vs. owned end property [message #474994 is a reply to message #474990]

Wed, 08 August 2007 14:00

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Manar,

The concepts of end ownership and navigability are two separate notions.
It is possible for an association to own an end and for that end to be
navigable.
Have a look at section 7.3.3 of the superstructure spec for explanation of
the "dot" notation on associations.

You mention that .."The navigable owned end property is usually owned by the
class on the opposite side ..." The key word here is "usually". That is
a convention that some tools use but other tools use a convention of the
naviagable ends being owned by the association.

Having the ends owned directly by the association better isolates
modifications such that changes to the association don't involve changes to
the classifiers involved in the association.

- James.

"Manar El-Kady" <manar.elkady@gmail.com> wrote in message
news:f9akf0$je7$1@build.eclipse.org...
> Hi,
>
> I'd like to ask about the difference between the navigable owned end
> property and the owned end property for the association?
> The navigable end property is usually owned by the class on the opposite
> side of the association, and the non-navigable end property is owned by
> the association itself. So, what is the need for the navigable owned end
> property for the association?
>
> Thanks in advance,
>
> Manar

Report message to a moderator

Re: navigable owned end property vs. owned end property [message #474999 is a reply to message #474994]

Wed, 08 August 2007 18:06

Dave Carlson

Messages: 402
Registered: July 2009

Senior Member

Hi,
I have some other practical observations on this difference, based on my
work using UML to model XML Schema (www.xmlmodeling.com).

An important design requirement in XSD complexTypes is the sequence of
elements. When navigable association ends are owned by the source class,
then one can reorder these properties in the class to design the needed
seqence, and this will generate the required XSD message. This was always a
problem for me in UML 1.x where there was no way to specify order of
association ends, so I had to use a stereotype on AssociationEnd (in UML
1.x) to add an 'position' property. This is *much* easier in UML2 where
class properties are ordered in the metamodel.

If the navigable properties are owned by the association in UML2, then there
is no way to model the required order of those properties in the source type
when generating to implementation languages where this is important (e.g.
XSD). So I always discourage this practice and prefer tools that default to
class-owned navigable ends. However, to allow for this in UML2, I've
created an <<element>> stereotype that may be applied to Property and
contains a 'position' value for this position of this element in the source
class elements. But this is error-prone and difficult to maintain.

A good use case for Association owned navigable ends is when you are
modeling an association from a class in a different package, and that source
package is read-only for you (e.g. maintained as a reusable library by a
different team). In that case, the navigable end cannot be added to the
source class because you cannot modify it, but the new association can be
added to your package. I have encountered this situation with a client
using IBM's RSM/A tools working with a large banking model.

Regards,
Dave Carlson

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:f9ci9a$724$1@build.eclipse.org...
> Hi Manar,
>
> The concepts of end ownership and navigability are two separate notions.
> It is possible for an association to own an end and for that end to be
> navigable.
> Have a look at section 7.3.3 of the superstructure spec for explanation of
> the "dot" notation on associations.
>
> You mention that .."The navigable owned end property is usually owned by
> the
> class on the opposite side ..." The key word here is "usually". That
> is
> a convention that some tools use but other tools use a convention of the
> naviagable ends being owned by the association.
>
> Having the ends owned directly by the association better isolates
> modifications such that changes to the association don't involve changes
> to
> the classifiers involved in the association.
>
> - James.
>
>
>
>
> "Manar El-Kady" <manar.elkady@gmail.com> wrote in message
> news:f9akf0$je7$1@build.eclipse.org...
>> Hi,
>>
>> I'd like to ask about the difference between the navigable owned end
>> property and the owned end property for the association?
>> The navigable end property is usually owned by the class on the opposite
>> side of the association, and the non-navigable end property is owned by
>> the association itself. So, what is the need for the navigable owned end
>> property for the association?
>>
>> Thanks in advance,
>>
>> Manar
>
>

Report message to a moderator

Re: navigable owned end property vs. owned end property [message #475000 is a reply to message #474999]

Wed, 08 August 2007 18:23

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010704090109040106020900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave,

This is not directly related to the topic at hand, but I'm curious how
you deal with the fact that XML Schema can't express multiple
inheritance? I've often asserted that XMI schemas (as outlined in the
XMI specification) are useless because they are simply an expensive way
to turn off validation. Is that a reasonable, if politically incorrect,
characterization? I also wonder, is an XML Schema that doesn't
accurately describe the actual XML serialization of an instance, but
that does closely mirror the abstract syntax of the model, useful for
anything? Inquiring minds are just dying to know the well informed
opinions of others... :-)

Dave Carlson wrote:
> Hi,
> I have some other practical observations on this difference, based on my
> work using UML to model XML Schema (www.xmlmodeling.com).
>
> An important design requirement in XSD complexTypes is the sequence of
> elements. When navigable association ends are owned by the source class,
> then one can reorder these properties in the class to design the needed
> seqence, and this will generate the required XSD message. This was always a
> problem for me in UML 1.x where there was no way to specify order of
> association ends, so I had to use a stereotype on AssociationEnd (in UML
> 1.x) to add an 'position' property. This is *much* easier in UML2 where
> class properties are ordered in the metamodel.
>
> If the navigable properties are owned by the association in UML2, then there
> is no way to model the required order of those properties in the source type
> when generating to implementation languages where this is important (e.g.
> XSD). So I always discourage this practice and prefer tools that default to
> class-owned navigable ends. However, to allow for this in UML2, I've
> created an <<element>> stereotype that may be applied to Property and
> contains a 'position' value for this position of this element in the source
> class elements. But this is error-prone and difficult to maintain.
>
> A good use case for Association owned navigable ends is when you are
> modeling an association from a class in a different package, and that source
> package is read-only for you (e.g. maintained as a reusable library by a
> different team). In that case, the navigable end cannot be added to the
> source class because you cannot modify it, but the new association can be
> added to your package. I have encountered this situation with a client
> using IBM's RSM/A tools working with a large banking model.
>
> Regards,
> Dave Carlson
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:f9ci9a$724$1@build.eclipse.org...
>
>> Hi Manar,
>>
>> The concepts of end ownership and navigability are two separate notions.
>> It is possible for an association to own an end and for that end to be
>> navigable.
>> Have a look at section 7.3.3 of the superstructure spec for explanation of
>> the "dot" notation on associations.
>>
>> You mention that .."The navigable owned end property is usually owned by
>> the
>> class on the opposite side ..." The key word here is "usually". That
>> is
>> a convention that some tools use but other tools use a convention of the
>> naviagable ends being owned by the association.
>>
>> Having the ends owned directly by the association better isolates
>> modifications such that changes to the association don't involve changes
>> to
>> the classifiers involved in the association.
>>
>> - James.
>>
>>
>>
>>
>> "Manar El-Kady" <manar.elkady@gmail.com> wrote in message
>> news:f9akf0$je7$1@build.eclipse.org...
>>
>>> Hi,
>>>
>>> I'd like to ask about the difference between the navigable owned end
>>> property and the owned end property for the association?
>>> The navigable end property is usually owned by the class on the opposite
>>> side of the association, and the non-navigable end property is owned by
>>> the association itself. So, what is the need for the navigable owned end
>>> property for the association?
>>>
>>> Thanks in advance,
>>>
>>> Manar
>>>
>>
>
>
>

--------------010704090109040106020900
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>
This is not directly related to the topic at hand, but I'm curious how
you deal with the fact that XML Schema can't express multiple
inheritance?  I've often asserted that XMI schemas (as outlined in the
XMI specification) are useless because they are simply an expensive way
to turn off validation.  Is that a reasonable, if politically
incorrect, characterization?  I also wonder, is an XML Schema that
doesn't accurately describe the actual XML serialization of an
instance, but that does closely mirror the abstract syntax of the
model, useful for anything?  Inquiring minds are just dying to know the
well informed opinions of others...  :-)<br>
<br>
<br>
Dave Carlson wrote:
<blockquote cite="mid:f9d0me$ujk$1@build.eclipse.org" type="cite">
<pre wrap="">Hi,
I have some other practical observations on this difference, based on my
work using UML to model XML Schema (<a class="moz-txt-link-abbreviated" href="http://www.xmlmodeling.com">www.xmlmodeling.com</a>).

An important design requirement in XSD complexTypes is the sequence of
elements. When navigable association ends are owned by the source class,
then one can reorder these properties in the class to design the needed
seqence, and this will generate the required XSD message. This was always a
problem for me in UML 1.x where there was no way to specify order of
association ends, so I had to use a stereotype on AssociationEnd (in UML
1.x) to add an 'position' property. This is *much* easier in UML2 where
class properties are ordered in the metamodel.

If the navigable properties are owned by the association in UML2, then there
is no way to model the required order of those properties in the source type
when generating to implementation languages where this is important (e.g.
XSD). So I always discourage this practice and prefer tools that default to
class-owned navigable ends. However, to allow for this in UML2, I've
created an <<element>> stereotype that may be applied to Property and
contains a 'position' value for this position of this element in the source
class elements. But this is error-prone and difficult to maintain.

A good use case for Association owned navigable ends is when you are
modeling an association from a class in a different package, and that source
package is read-only for you (e.g. maintained as a reusable library by a
different team). In that case, the navigable end cannot be added to the
source class because you cannot modify it, but the new association can be
added to your package. I have encountered this situation with a client
using IBM's RSM/A tools working with a large banking model.

Regards,
Dave Carlson

"James Bruck" <a class="moz-txt-link-rfc2396E" href="mailto:jbruck@ca.ibm.com"><jbruck@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:f9ci9a$724$1@build.eclipse.org">news:f9ci9a$724$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Manar,

The concepts of end ownership and navigability are two separate notions.
It is possible for an association to own an end and for that end to be
navigable.
Have a look at section 7.3.3 of the superstructure spec for explanation of
the "dot" notation on associations.

You mention that .."The navigable owned end property is usually owned by
the
class on the opposite side ..." The key word here is "usually". That
is
a convention that some tools use but other tools use a convention of the
naviagable ends being owned by the association.

Having the ends owned directly by the association better isolates
modifications such that changes to the association don't involve changes
to
the classifiers involved in the association.

- James.

"Manar El-Kady" <a class="moz-txt-link-rfc2396E" href="mailto:manar.elkady@gmail.com"><manar.elkady@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:f9akf0$je7$1@build.eclipse.org">news:f9akf0$je7$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I'd like to ask about the difference between the navigable owned end
property and the owned end property for the association?
The navigable end property is usually owned by the class on the opposite
side of the association, and the non-navigable end property is owned by
the association itself. So, what is the need for the navigable owned end
property for the association?

Thanks in advance,

Manar
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
<br>
</body>
</html>

--------------010704090109040106020900--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: navigable owned end property vs. owned end property [message #475127 is a reply to message #475000]

Mon, 13 August 2007 16:42

Dave Carlson

Messages: 402
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C7DD96.B6F45FD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ed,
I missed your question last week. See my comments below.
-- Dave
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:f9d1n2$5kb$1@build.eclipse.org...
Dave,

This is not directly related to the topic at hand, but I'm curious how =
you deal with the fact that XML Schema can't express multiple =
inheritance? =20

<dave> This is mostly a non-issue among the modelers and data =
architects that I work with. In the past 6+ years I've received a lot =
of email about UML-XSD mapping and I recall only one query about =
multiple inheritance. And that was from a graduate student writing a =
thesis. Multiple inheritance is very important in complex metamodel =
definitions such as UML, but the business models and XSD specs that I =
work with are mostly about defining system interoperability standards =
and SOA messages. In fact, I sometimes have a challenge getting =
modelers to use inheritance at all when they think in terms of =
aggegation of structures as they appear in XML instances. Multiple =
inheritance can be useful here, but is rarely used.

However, if I were to support multiple inheritance in XSD generation =
from UML, I would probably use a <<mixin>> stereotype similar to Ecore =
and use "copy-down inheritance" to copy the mixed-in elements/attributes =
into extended XSD complexTypes. But this would be difficult or =
impossible to detect when importing XSD into UML.

I've often asserted that XMI schemas (as outlined in the XMI =
specification) are useless because they are simply an expensive way to =
turn off validation. Is that a reasonable, if politically incorrect, =
characterization? =20

<dave> The XMI spec is excellent for serializing metamodels like UML =
or Ecore, but mostly useless when defining XSD for data interoperability =
standards. I communicate with a lot of industry standards groups, and =
all are *very* particular about the XML Schemas that they deliver as =
standards. None of them would accept the XMI spec serialization rules.

If you ignore the XMI serialization rules, then XSD can be designed =
with a bit better validation, although still limited compared to the =
model. A growing number of data interoperability standards groups are =
interested in using UML to design and/or visualize their standards, but =
I've yet to find one who is able to use UML as the normative definition. =
The delivered XSD are still the basis for an approved standard. A few =
groups are attempting to use Schematron rules for supplementary =
validation that go beyond XSD (e.g. the CDA R2 subgroup of HL7 =
healthcare). I plan to start looking at generating Schematron =
constraits in XSD annotations, using UML models and constraints as the =
source definition. Obviously you are thinking about the benefits of =
EMF. I couldn't agree more. But most of the groups I work with don't =
use EMF, or require an implementation independent SOA message =
specification.

I also wonder, is an XML Schema that doesn't accurately describe the =
actual XML serialization of an instance, but that does closely mirror =
the abstract syntax of the model, useful for anything? Inquiring minds =
are just dying to know the well informed opinions of others... :-)

<dave> In fact, I find quite a few needs for "relaxed" XSD that mirror =
the model abstract syntax. But they *must* accurately describe the XML =
instances, although allow more instances to pass through as "valid". =
Most often, these relaxed schemas simply change minOccurs of all =
elements to 0, makes attributes optional, and maybe omits simpleType =
facet constraints. My UML to XSD generator has this option.

But back to the original question of this post, most of these =
"relaxed" schemas still must use xsd:sequence and this sequence must =
accurately describe the XML instances. So generating relaxed XSD from =
UML still required knowledge of element order. The original XMI 1.0 =
spec defined relaxed schemas/DTDs by using xsd:choice groups for all =
content. I find this to be mostly useless as it eliminates all =
multiplicity constraints. So we are stil stuck with needing specific =
and consistent sequence definition in the models and corresponding XSD.

My 2 cents,
Dave Carlson

------=_NextPart_000_000E_01C7DD96.B6F45FD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I missed your question last week.  =
See my=20
comments below.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> -- Dave</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:f9d1n2$5kb$1@build.eclipse.org">news:f9d1n2$5kb$1@build.ecli=
pse.org</A>...</DIV>
<DIV>Dave,<BR><BR>This is not directly related to the topic at hand, =
but I'm=20
curious how you deal with the fact that XML Schema can't express =
multiple=20
inheritance?  </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><dave> This is =
mostly a=20
non-issue among the modelers and data architects that I work =
with.  In=20
the past 6+ years I've received a lot of email about UML-XSD mapping =
and I=20
recall only one query about multiple inheritance.  And that was =
from a=20
graduate student writing a thesis.  Multiple inheritance is very=20
important in complex metamodel definitions such as UML, but the =
business=20
models and XSD specs that I work with are mostly about defining =
system=20
interoperability standards and SOA messages.  In fact, =
I sometimes=20
have a challenge getting modelers to use inheritance at all when they =
think in=20
terms of aggegation of structures as they appear in XML =
instances. =20
Multiple inheritance can be useful here, but is rarely =
used.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>However, if I were to =
support=20
multiple inheritance in XSD generation from UML, I would probably use =
a=20
<<mixin>> stereotype similar to Ecore and use "copy-down=20
inheritance" to copy the mixed-in elements/attributes into extended =
XSD=20
complexTypes.  But this would be difficult or impossible to =
detect when=20
importing XSD into UML.</FONT></DIV>
<DIV> </DIV>
<DIV>I've often asserted that XMI schemas (as outlined in the XMI=20
specification) are useless because they are simply an expensive way to =
turn=20
off validation.  Is that a reasonable, if politically incorrect,=20
characterization?  </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><dave> The XMI =
spec is=20
excellent for serializing metamodels like UML or Ecore, but mostly =
useless=20
when defining XSD for data interoperability standards.  I =
communicate=20
with a lot of industry standards groups, and all are *very* particular =
about=20
the XML Schemas that they deliver as standards.  None of them =
would=20
accept the XMI spec serialization rules.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>If you ignore the XMI =
serialization=20
rules, then XSD can be designed with a bit better validation, although =
still=20
limited compared to the model.  A growing number of data =
interoperability=20
standards groups are interested in using UML to design and/or =
visualize their=20
standards, but I've yet to find one who is able to use UML as the =
normative=20
definition.  The delivered XSD are still the basis for an =
approved=20
standard.  A few groups are attempting to use Schematron rules =
for=20
supplementary validation that go beyond XSD (e.g. the CDA R2 subgroup =
of HL7=20
healthcare).  I plan to start looking at generating Schematron =
constraits=20
in XSD annotations, using UML models and constraints as the source=20
definition.  Obviously you are thinking about the benefits of =
EMF. =20
I couldn't agree more.  But most of the groups I work with don't =
use EMF,=20
or require an implementation independent SOA message=20
specification.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>I also wonder, is an XML Schema that doesn't accurately describe =
the=20
actual XML serialization of an instance, but that does closely mirror =
the=20
abstract syntax of the model, useful for anything?  Inquiring =
minds are=20
just dying to know the well informed opinions of others...  =
:-)<BR></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><dave> In fact, =
I find quite=20
a few needs for "relaxed" XSD that mirror the model abstract =
syntax.  But=20
they *must* accurately describe the XML instances, although allow more =

instances to pass through as "valid".  Most often, these relaxed =
schemas=20
simply change minOccurs of all elements to 0, makes attributes =
optional, and=20
maybe omits simpleType facet constraints.  My UML to XSD =
generator has=20
this option.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>But back to the =
original question=20
of this post, most of these "relaxed" schemas still must use =
xsd:sequence and=20
this sequence must accurately describe the XML instances.  So =
generating=20
relaxed XSD from UML still required knowledge of element order.  =
The=20
original XMI 1.0 spec defined relaxed schemas/DTDs by using xsd:choice =
groups=20
for all content.  I find this to be mostly useless as it =
eliminates all=20
multiplicity constraints.  So we are stil stuck with needing =
specific and=20
consistent sequence definition in the models and=20
corresponding XSD.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>My 2 =
cents,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>  Dave =
Carlson</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML >

------=_NextPart_000_000E_01C7DD96.B6F45FD0--

Report message to a moderator

Re: navigable owned end property vs. owned end property [message #475129 is a reply to message #475127]

Mon, 13 August 2007 17:30

Ed Merks

Messages: 33141
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------080909060201050701080704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave Carlson wrote:
> Hi Ed,
> I missed your question last week. See my comments below.
> -- Dave
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:f9d1n2$5kb$1@build.eclipse.org...
> Dave,
>
> This is not directly related to the topic at hand, but I'm curious
> how you deal with the fact that XML Schema can't express multiple
> inheritance?
>
> <dave> This is mostly a non-issue among the modelers and data
> architects that I work with. In the past 6+ years I've received a
> lot of email about UML-XSD mapping and I recall only one query
> about multiple inheritance. And that was from a graduate student
> writing a thesis. Multiple inheritance is very important in
> complex metamodel definitions such as UML, but the business models
> and XSD specs that I work with are mostly about defining system
> interoperability standards and SOA messages. In fact, I sometimes
> have a challenge getting modelers to use inheritance at all when
> they think in terms of aggegation of structures as they appear in
> XML instances. Multiple inheritance can be useful here, but is
> rarely used.
>
> However, if I were to support multiple inheritance in XSD
> generation from UML, I would probably use a <<mixin>> stereotype
> similar to Ecore and use "copy-down inheritance" to copy the
> mixed-in elements/attributes into extended XSD complexTypes. But
> this would be difficult or impossible to detect when importing XSD
> into UML.
>
Yes, multiple inheritance is quite a problematic concept to support
well. When exporting Ecore to an XML Schema, we use an ecore:extends
annotation to list additional super types, but there's no copying of the
multiple inherited things, so the schema is only useful as a way to
round trip the Ecore model and not for validating serialized instances.
It's just impossible for xsi:type to work properly anyway, so there's no
point in trying.
>
>
> I've often asserted that XMI schemas (as outlined in the XMI
> specification) are useless because they are simply an expensive
> way to turn off validation. Is that a reasonable, if politically
> incorrect, characterization?
>
> <dave> The XMI spec is excellent for serializing metamodels like
> UML or Ecore, but mostly useless when defining XSD for data
> interoperability standards. I communicate with a lot of industry
> standards groups, and all are *very* particular about the XML
> Schemas that they deliver as standards. None of them would accept
> the XMI spec serialization rules.
>
No, I didn't think so!
>
>
> If you ignore the XMI serialization rules, then XSD can be
> designed with a bit better validation, although still limited
> compared to the model. A growing number of data interoperability
> standards groups are interested in using UML to design and/or
> visualize their standards, but I've yet to find one who is able to
> use UML as the normative definition. The delivered XSD are still
> the basis for an approved standard.
>
Yet that doesn't allow you to model typed references, container
references, or bidirectional references. XML Schema is definite a poor
man's modeling language that's mostly obsessed with concrete syntax
rather than with semantics. But I suppose that makes sense when the
point is to exchange serialized documents.
>
> A few groups are attempting to use Schematron rules for
> supplementary validation that go beyond XSD (e.g. the CDA R2
> subgroup of HL7 healthcare). I plan to start looking at
> generating Schematron constraits in XSD annotations, using UML
> models and constraints as the source definition. Obviously you
> are thinking about the benefits of EMF. I couldn't agree more.
> But most of the groups I work with don't use EMF, or require an
> implementation independent SOA message specification.
>
I tend to see how most of these things as roughly equivalent anyway, so
if you have an Ecore model but someone wants an XML Schema, just be
sure you are using an XML serialization rather than an XMI serialization
and you can export the schema to give them their desire. If people get
fussed out over element verses attribute, just add some extended
metadata annotations to control it the way folks want.
>
>
> I also wonder, is an XML Schema that doesn't accurately describe
> the actual XML serialization of an instance, but that does closely
> mirror the abstract syntax of the model, useful for anything?
> Inquiring minds are just dying to know the well informed opinions
> of others... :-)
> <dave> In fact, I find quite a few needs for "relaxed" XSD that
> mirror the model abstract syntax. But they *must* accurately
> describe the XML instances, although allow more instances to pass
> through as "valid". Most often, these relaxed schemas simply
> change minOccurs of all elements to 0, makes attributes optional,
> and maybe omits simpleType facet constraints. My UML to XSD
> generator has this option.
>
I see. That makes good sense. Never say a correct thing is incorrect,
which is at the cost of saying an incorrect thing is correct. The XMI
schema does this to the extreme by effectively not using data types at all.
>
>
> But back to the original question of this post, most of these
> "relaxed" schemas still must use xsd:sequence and this sequence
> must accurately describe the XML instances. So generating relaxed
> XSD from UML still required knowledge of element order. The
> original XMI 1.0 spec defined relaxed schemas/DTDs by using
> xsd:choice groups for all content. I find this to be mostly
> useless as it eliminates all multiplicity constraints. So we are
> stil stuck with needing specific and consistent sequence
> definition in the models and corresponding XSD.
>
Yes, and it doesn't solve the problem that base content must come before
derived content since derivation via extension involves an implicit
<sequence>. Thanks for sharing your thoughts! In
https://bugs.eclipse.org/bugs/show_bug.cgi?id=51210
I was experimenting with with representing the element particle
structure as annotations so that full validation of the particle
constraints, including type restriction could be expressed. I just
can't find the time to complete the work, document it, and make the
commitment to support it forever...
>
>
> My 2 cents,
> Dave Carlson
>
>

--------------080909060201050701080704
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 Carlson wrote:
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16481" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Ed,</font></div>
<div><font face="Arial" size="2">I missed your question last week. 
See my comments below.</font></div>
<div><font face="Arial" size="2"> -- Dave</font></div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:f9d1n2$5kb$1@build.eclipse.org">news:f9d1n2$5kb$1@build.eclipse.org</a>...</div>
<div>Dave,<br>
<br>
This is not directly related to the topic at hand, but I'm curious how
you deal with the fact that XML Schema can't express multiple
inheritance?  </div>
<div> </div>
<div><font color="#0000ff" face="Arial" size="2"><dave> This
is mostly a non-issue among the modelers and data architects that I
work with.  In the past 6+ years I've received a lot of email about
UML-XSD mapping and I recall only one query about multiple
inheritance.  And that was from a graduate student writing a thesis. 
Multiple inheritance is very important in complex metamodel definitions
such as UML, but the business models and XSD specs that I work with are
mostly about defining system interoperability standards and SOA
messages.  In fact, I sometimes have a challenge getting modelers to
use inheritance at all when they think in terms of aggegation of
structures as they appear in XML instances.  Multiple inheritance can
be useful here, but is rarely used.</font></div>
<div> </div>
<div><font color="#0000ff" face="Arial" size="2">However, if I were
to support multiple inheritance in XSD generation from UML, I would
probably use a <<mixin>> stereotype similar to Ecore and
use "copy-down inheritance" to copy the mixed-in elements/attributes
into extended XSD complexTypes.  But this would be difficult or
impossible to detect when importing XSD into UML.</font></div>
</blockquote>
</blockquote>
Yes, multiple inheritance is quite a problematic concept to support
well. When exporting Ecore to an XML Schema, we use an ecore:extends
annotation to list additional super types, but there's no copying of
the multiple inherited things, so the schema is only useful as a way to
round trip the Ecore model and not for validating serialized
instances.  It's just impossible for xsi:type to work properly anyway,
so there's no point in trying.<br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div> </div>
<div>I've often asserted that XMI schemas (as outlined in the XMI
specification) are useless because they are simply an expensive way to
turn off validation.  Is that a reasonable, if politically incorrect,
characterization?  </div>
<div> </div>
<div><font color="#0000ff" face="Arial" size="2"><dave> The
XMI spec is excellent for serializing metamodels like UML or Ecore, but
mostly useless when defining XSD for data interoperability standards. 
I communicate with a lot of industry standards groups, and all are
*very* particular about the XML Schemas that they deliver as
standards.  None of them would accept the XMI spec serialization rules.</font></div>
</blockquote>
</blockquote>
No, I didn't think so!<br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div> </div>
<div><font color="#0000ff" face="Arial" size="2">If you ignore the
XMI serialization rules, then XSD can be designed with a bit better
validation, although still limited compared to the model.  A growing
number of data interoperability standards groups are interested in
using UML to design and/or visualize their standards, but I've yet to
find one who is able to use UML as the normative definition.  The
delivered XSD are still the basis for an approved standard. <br>
</font></div>
</blockquote>
</blockquote>
Yet that doesn't allow you to model typed references, container
references, or bidirectional references.  XML Schema is definite a poor
man's modeling language that's mostly obsessed with concrete syntax
rather than with semantics.  But I suppose that makes sense when the
point is to exchange serialized documents.<br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div><font color="#0000ff" face="Arial" size="2"> A few groups are
attempting to use Schematron rules for supplementary validation that go
beyond XSD (e.g. the CDA R2 subgroup of HL7 healthcare).  I plan to
start looking at generating Schematron constraits in XSD annotations,
using UML models and constraints as the source definition.  Obviously
you are thinking about the benefits of EMF.  I couldn't agree more. 
But most of the groups I work with don't use EMF, or require an
implementation independent SOA message specification.</font></div>
</blockquote>
</blockquote>
I tend to see how most of these things as roughly equivalent anyway, so
if you have an Ecore model but someone wants an XML Schema,  just be
sure you are using an XML serialization rather than an XMI
serialization and you can export the schema to give them their desire. 
If people get fussed out over element verses attribute, just add some
extended metadata annotations to control it the way folks want. <br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div> </div>
<div>I also wonder, is an XML Schema that doesn't accurately
describe the actual XML serialization of an instance, but that does
closely mirror the abstract syntax of the model, useful for anything? 
Inquiring minds are just dying to know the well informed opinions of
others...  :-)<br>
</div>
<div><font color="#0000ff" face="Arial" size="2"><dave> In
fact, I find quite a few needs for "relaxed" XSD that mirror the model
abstract syntax.  But they *must* accurately describe the XML
instances, although allow more instances to pass through as "valid". 
Most often, these relaxed schemas simply change minOccurs of all
elements to 0, makes attributes optional, and maybe omits simpleType
facet constraints.  My UML to XSD generator has this option.</font></div>
</blockquote>
</blockquote>
I see.  That makes good sense. Never say a correct thing is incorrect,
which is at the cost of saying an incorrect thing is correct.  The XMI
schema does this to the extreme by effectively not using data types at
all.<br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div> </div>
<div><font color="#0000ff" face="Arial" size="2">But back to the
original question of this post, most of these "relaxed" schemas still
must use xsd:sequence and this sequence must accurately describe the
XML instances.  So generating relaxed XSD from UML still required
knowledge of element order.  The original XMI 1.0 spec defined relaxed
schemas/DTDs by using xsd:choice groups for all content.  I find this
to be mostly useless as it eliminates all multiplicity constraints.  So
we are stil stuck with needing specific and consistent sequence
definition in the models and corresponding XSD.</font></div>
</blockquote>
</blockquote>
Yes, and it doesn't solve the problem that base content must come
before derived content since derivation via extension involves an
implicit <sequence>.  Thanks for sharing your thoughts!  In <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=51210">https://bugs.eclipse.org/bugs/show_bug.cgi?id=51210</a><br>
I was experimenting with with representing the element  particle
structure as annotations so that full validation of the particle
constraints, including type restriction could be expressed.  I just
can't find the time to complete the work, document it, and make the
commitment to support it forever...<br>
<blockquote cite="mid:f9q1mg$fod$1@build.eclipse.org" type="cite">
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div> </div>
<div><font color="#0000ff" face="Arial" size="2">My 2 cents,</font></div>
<div><font color="#0000ff" face="Arial" size="2">  Dave Carlson</font></div>
<div> </div>
</blockquote>
</blockquote>
<br>
</body>
</html>

--------------080909060201050701080704--

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator