RE: Impact of XML on Data Modeling

My experience strongly endorses Tony's themes here, but I resist the urge to indulge in war stories.  This last post squarely addresses my current pre-occupation.  So a couple of observations and questions.
 
Implementing in XSD should not impact your approach to modelling if you already have one.  In my current environment, a business area data model (a normalized E-R model that details the business data requirements), seeded by any relevant content from a nascent Enterprise Data Model, is the common basis for the physical design of operational databases, extensions to the enterprise data warehouse, and data marts - where star schema dimensional modelling criteria are very different from those of operational databases.  So XML schemas are just another implementation medium.  Much of the benefit of a common data model (: we studiously avoid the term "logical" :) is that it propagates common semantics and naming standards across implementations, e.g. allows for the consistent mapping of 11179 representation terms to W3C Data Types and the reuse of your metadata management efforts.  This is particularly beneficial for building a consistent XML facade for the outside world.
 
Nor do I see any real dichotomy between message design and database design.  While XSD is essentially hierarchical and message design is often driven by the loose collections of data found on forms, or just a list of cherry-picked elements, rather than normalized business entities, there is a whole spectrum of uses out there.  I recently developed a schema for what could only be called a database in motion.  The application was analogous to a university prospectus/curriculum with information about courses, classes, lecturers and room assignments, where many-to-many relationships were resolved using key/keyref, and was used to refresh a variety of personal productivity packages which used it as reference data.
 
I now need to define an approach to XML reuse in an organization that is typically the 800-pound gorilla in the room, rather than a peer in a data exchange community (i.e. no appetite for UBL, OAGIS, etc), but where the management of the different business lines like to maintain fences between themselves, encouraged by the IT funding model.  I assume your apprehension about tying everything together with namespace includes/imports is a lack of flexibility in practice?  Could you expand on that, please?
 
Are there others with experiences to share in this arena?  Pitfalls to avoid?
 
I've just been reading (Uh oh! pointy-haired manager alert!) about canonical information models using XSD which sounds like a Nike approach to information architecture.  Observations?
 
Cheers
               Jack Lindsey
 
 
 



> Date: Thu, 31 Jan 2008 11:13:11 +0000> To: xmlschema-dev@w3.org> From: abcoatesecure-w3c@yahoo.co.uk> Subject: Re: Impact of XML on Data Modeling> > > I personally wouldn't prefer to use W3C XML Schemas directly when creating > a large set of Schemas which share type definitions. A couple of years > ago, I used IONA Artix Data Services (formerly C24 Integration Objects) to > create a type repository from which we designed and generated over 450 > Schemas for a banking/finance client. That worked very successfully, and > my personal approach is to use some kind of type repository and generate > independent Schemas from that.> > That said, I know that when Dan Vint was at ACORD (XML for insurance), > they generated 600-700 Schemas (some number like that) from a master > Schema. Now, that's not my personal preferred approach, but clearly it > can work, and in practice the choice of which way to go will also depend > on the tools and skills available to and in your team.> > 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).> > I mention this because "success stories" depend just as much on setting up > the right "distributed versus centralised" design process for your message > development, as they do on any particular technology. Just what is right > depends on your circumstances, there is no "one size fits all" answer ("no > best practices", as I like to say).> > Cheers, Tony.> > On Thu, 31 Jan 2008 01:42:06 -0000, Tsao, Scott <scott.tsao@boeing.com> > wrote:> > > Count me in as one of those "large organizations!" Is it ever> > achievable? Any successful stories?> >> > Given that as a goal (and constraint), will XSD still be a good (or> > best) choice for message design?> > Thanks,> >> >> >> > Scott Tsao> > Associate Technical Fellow> > The Boeing Company> >> >> > -----Original Message-----> > From: Anthony B. Coates (Work) [mailto:abcoates.work@yahoo.co.uk]> > Sent: Wednesday, January 30, 2008 4:02 PM> > To: xmlschema-dev@w3.org> > Subject: Re: Impact of XML on Data Modeling> >> >> > Designing in XML (e.g. W3C XML Schema) is an attractive option when you> > (and/or your group) are only responsible for the messages that are sent> > between systems. On the other hand, I know a number of large> > organisations that are busy developing enterprise data models, at a> > level above XML or relational databases or program code, because they> > want data consistency everywhere. They are concerned with more than> > just consistency in the messaging between systems.> >> > So whether XML schemas are suitable for your modelling needs depends> > very much on what your business scope is, and what your company's longer> > term> > ambitions are (in terms of having a consistent enterprise data model).> > The "right" choice depends very much on your particular needs and goals.> >> > Cheers, Tony.> > -- > Anthony B. Coates> London, UK> UK: +44 (20) 8816 7700, US: +1 (239) 344 7700> Mobile/Cell: +44 (79) 0543 9026> abcoates.work@yahoo.co.uk> 
_________________________________________________________________