RE: Impact of XML on Data Modeling

Sorry I'm late to this thread, finally got a moment to breathe.  

This thread seems to lead toward what I have found to be the case with my
clients.  Namely that the "ideal" is to use UML for a conceptual (and
business friendly) view of a canonical model.  And XSD is the "ideal"
physical representation of the (techie friendly) canonical model.  I say
"friendly" in both situations because as Michael Kay points out, the line
between them can be unclear.  The UML is used to show business folks what
the data looks like.  XSD is used to govern actual implementation.  Both are
ideally based on a canonical data model.

 

The wrinkle (and some of you have said this) is that XSD can also represent
the conceptual.  I have certainly seen this.  One set of schemas for a
generalized data model and another to validate incoming messages with.  So I
always tell clients when they ask me which is better - is to look at
usability.  Pick a tool and a technology that works for your enterprise.
Some have lots of experience with UML and love it, others like XSD and are
comfortable with it.  The best laid data model doesn't work if no one can
use it.  I think it is more important to have a tool that is comfortable to
folks than which technology you actually use.  

 

The big problem with a conceptual=UML and physical=XSD breakdown is the
translation between the two.  Having done this via tool (quick and easy but
with assumptions) and stylesheet (harder, but with a profile that works for
the company).  One can either accept the translation that tools use or
transform it yourself with a profile. 

 

0.02,

Paul Kiel

 

=====================================================

W. Paul Kiel

xmlHelpline.com Consulting

paul@xmlhelpline.com

work: 919-846-0224

cell: 919-449-8801

website: http://www.xmlhelpline.com

Your helpline for data integration solutions.

=====================================================

 

 

 

 

  _____  

From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Tsao, Scott
Sent: Tuesday, February 05, 2008 12:00 AM
To: abcoatesecure-w3c@yahoo.co.uk; xmlschema-dev@w3.org
Subject: RE: Impact of XML on Data Modeling

 

The scenario described below seems to be quite REAL in large organizations,
where the Central Team is more interested in developing a "common data
model" reflecting the overall business of the enterprise, but the
Distributed Teams are more interested in developing the "localized XML
schemas" to facilitate interfaces between applications (or with data
warehouse).

I wonder in the case that the Central Team's modeling effort is lagging
behind the localized schema development, would it be advisable to reverse
engineer the XML schemas for the sake of maintaining a data model that
reflects the actual implementation?  Have you experienced that in your
practices?

 

Thanks,

 

Scott

-----Original Message-----
From: Anthony B. Coates (W3C Lists) [mailto:abcoatesecure-w3c@yahoo.co.uk]
Sent: Thursday, January 31, 2008 3:13 AM
To: xmlschema-dev@w3.org
Subject: Re: Impact of XML on Data Modeling

...

At this scale, though, it's not just about the technology, there are also
important project management issues which can contribute just as much to
success and failure.  For example, if all of the Schema
creation/editing/generation (depending on your process) is done by a central
team, then during periods of heavy development that central team will find
itself on the critical path of a lot of work, and that can have a negative
impact on the way the central team is perceived.

The problem is one that transcends XML, it applies to many other things too
- how to you manage distributed design and development of shared assets?
Central teams are good as pools of technical expertise, and as custodians
who can check work against design rules and policies, provide guidance,
manage formal releases, etc.  Distributed teams sometimes have more of the
business knowledge, plus they have their own resources which they would
often prefer to use rather than waiting for their work to get to the top of
the queue of work for the central team (central teams are forced to
prioritise work from different teams, and that can be hard to do - why is
one team's work more important than another? - and that's no way to win
friends and influence people).

...

Cheers, Tony.