My experience strongly endorses Tony's themes here, but I resist the urge t=
o 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 alr=
eady have one.  In my current environment, a business area data model (a no=
rmalized E-R model that details the business data requirements), seeded by =
any relevant content from a nascent Enterprise Data Model, is the common ba=
sis for the physical design of operational databases, extensions to the ent=
erprise data warehouse, and data marts - where star schema dimensional mode=
lling 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 i=
t 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 par=
ticularly beneficial for building a consistent XML facade for the outside w=
orld.
 
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-p=
icked elements, rather than normalized business entities, there is a whole =
spectrum of uses out there.  I recently developed a schema for what could o=
nly be called a database in motion.  The application was analogous to a uni=
versity prospectus/curriculum with information about courses, classes, lect=
urers and room assignments, where many-to-many relationships were resolved =
using key/keyref, and was used to refresh a variety of personal productivit=
y packages which used it as reference data.
 
I now need to define an approach to XML reuse in an organization that is ty=
pically the 800-pound gorilla in the room, rather than a peer in a data exc=
hange community (i.e. no appetite for UBL, OAGIS, etc), but where the manag=
ement of the different business lines like to maintain fences between thems=
elves, encouraged by the IT funding model.  I assume your apprehension abou=
t tying everything together with namespace includes/imports is a lack of fl=
exibility in practice?  Could you expand on that, please?
 
Are there others with experiences to share in this arena?  Pitfalls to avoi=
d?
 
I've just been reading (Uh oh! pointy-haired manager alert!) about canonica=
l information models using XSD which sounds like a Nike approach to informa=
tion architecture.  Observations?
 
Cheers
               Jack Lindsey
 
 
 



> Date: Thu, 31 Jan 2008 11:13:11 +0000> To: xmlschema-dev@w...> From: ab=
coatesecure-w3c@y...> Subject: Re: Impact of XML on Data Modeling> >=
 > I personally wouldn't prefer to use W3C XML Schemas directly when creati=
ng > 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 w=
as at ACORD (XML for insurance), > they generated 600-700 Schemas (some num=
ber like that) from a master > Schema. Now, that's not my personal preferre=
d 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 yo=
ur team.> > At this scale, though, it's not just about the technology, ther=
e are also > important project management issues which can contribute just =
as much to > success and failure. For example, if all of the Schema > creat=
ion/editing/generation (depending on your process) is done by a > central t=
eam, 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 negati=
ve impact on the way the central team is perceived.> > The problem is one t=
hat transcends XML, it applies to many other things > too - how to you mana=
ge distributed design and development of shared > assets? Central teams are=
 good as pools of technical expertise, and as > custodians who can check wo=
rk against design rules and policies, provide > guidance, manage formal rel=
eases, etc. Distributed teams sometimes have > more of the business knowled=
ge, plus they have their own resources which > they would often prefer to u=
se rather than waiting for their work to get > to the top of the queue of w=
ork for the central team (central teams are > forced to prioritise work fro=
m different teams, and that can be hard to do > - why is one team's work mo=
re important than another? - and that's no way > to win friends and influen=
ce 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. Ju=
st what is right > depends on your circumstances, there is no "one size fit=
s 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@b...> >=
 wrote:> > > Count me in as one of those "large organizations!" Is it ever>=
 > achievable? Any successful stories?> >> > Given that as a goal (and cons=
traint), will XSD still be a good (or> > best) choice for message design?> =
> Thanks,> >> >> >> > Scott Tsao> > Associate Technical Fellow> > The Boein=
g Company> >> >> > -----Original Message-----> > From: Anthony B. Coates (W=
ork) [mailto:abcoates.work@y...]> > Sent: Wednesday, January 30, 200=
8 4:02 PM> > To: xmlschema-dev@w...> > 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 message=
s that are sent> > between systems. On the other hand, I know a number of l=
arge> > 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> > ju=
st consistency in the messaging between systems.> >> > So whether XML schem=
as 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" cho=
ice depends very much on your particular needs and goals.> >> > Cheers, Ton=
y.> > -- > Anthony B. Coates> London, UK> UK: +44 (20) 8816 7700, US: +1 (2=
39) 344 7700> Mobile/Cell: +44 (79) 0543 9026> abcoates.work@y...> 
_________________________________________________________________