XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Incongruous UML data models and XSD data models

Steve:

As usual I agree with you and I do on this point as well!  

However, I am not sure what prompted Roger's question but it may be from some of the same frustration that I have experienced with large projects that use UML for the conceptual model.  UML is great for conceptualizing and visualizing data models.  The problem arises when the conceptual model derives the physical (XML) model.  Large projects are sold on the concept that one UML software tool  can be used for both the conceptual and physical model.  The XML data model is produced directly from the UML model within the UML software. The result, unfortunately, is a complicated data model that lacks the natural inheritance of an XML data model.  

Personally I believe deriving the XML data model directly from the UML model without human intervention is a dead-wrong approach and I have the scars to prove it!

I would love to see a 'standard' graphical representation of an XML model.  When talking to UML folks about the capability of graphical representation of XML schemas/DTD's available in XML tools it is disregarded because XML doesn't have a standard graphical representation of the data model.  Each XML tool has derived their own graphical representation of the data model.   

Betty





On Sun, Jun 26, 2016 at 11:00 AM, Steve Newcomb <srn@coolheads.com> wrote:


On 06/26/2016 09:03 AM, Costello, Roger L. wrote:

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?


I disagree with the way you're thinking about this.  Normally, the concerns of communications (data interchange) differ from those of processing the data for some purpose

Project success requires that:

(1) Those with conflicting concerns endeavor to stay out of each other's way. 

(2) Some adaptable person, one not encumbered by exclusive devotion to some doctrine or formalism, has both responsibility and authority for the maintenance of some unifying, encompassing vision. 

With all that in mind, it's hard for me to imagine a project whose "objective is to validate data against an XML Schema".  It's a case of "one hand clapping."









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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS