[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Incongruous UML data models and XSD data models

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: "Roger L. Costello" <costello@mitre.org>
  • Date: Sat, 16 Jul 2016 12:23:30 +1000

Re:  Incongruous UML data models and XSD data models

Is the premise correct?  Why would you IDREF not KEYREF?

Regards
Rick


On 26/06/2016 11:04 PM, "Costello, Roger L." <costello@mitre.org> wrote:

Hi Folks,

 

[Definition] Incongruous: not harmonious in character; inconsonant; lacking harmony of parts; inconsistent.

 

There appears to be an incongruity in modeling data using UML versus modeling data using XML Schema (XSD).

 

Consider the situation where there are lots of chunks of data and the chunks are highly interrelated.

 

Example: You have data about an aircraft in flight: its current location, speed, heading, etc. So in UML you create a AircraftInFlight class:

 

In XSD you create a AircraftInFlight element:

You have data about the aircraft itself: fuel capacity, max speed, max altitude, cruising speed, date built, model number, etc. In UML you create a AircraftSpecification class:

In XSD you create a AircraftSpecification element:

You have data about the destination and originating points of the aircraft. In UML you create AircraftDestination and AicraftOrigination classes:

In XSD you create AircraftDestination and AicraftOrigination elements:

You wish to relate these chunks together; that way, if you are looking at the AircraftInFlight data you can hop over to the AircraftSpecification data (or any of the other chunks). In UML you make an abstract superclass and make all the other classes a subclass:

Then you state that any subclass of AircraftStuff can be related to any other subclass:

With that, XSD diverges from UML.

In XSD you create a Relationship element:

It can relate any two elements.

Here is a sample XML instance document:

Let’s recap the difference between modeling the data using UML versus using XSD:

- UML specifies a class (AircraftRelationship) that restricts the allowable relationships to subclasses of AircraftStuff.

- XSD specifies an element (Relation) that says nothing about what things may be related. The Relation element is a generic mechanism for relating any two things.

Therefore …. A UML model will yield different results than an XSD model. In fact, the above UML model doesn’t map to the XSD model.

Therefore …. If the objective is to validate data against an XML Schema it would be better to use XSD to model the data, not UML. Similarly, if the objective is to validate data against a JSON Schema it would be better to use JSON Schema to model the data. General principle: to model data, use the data modeling language of your data format (XSD for XML, JSON Schema for JSON, etc.).

Do you agree?

/Roger

 

 

 

 

 

 

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.