- From: Anthony B. Coates (W3C Lists) <abcoatesecure-w3c@yahoo.co.uk>
- Date: Thu, 31 Jan 2008 11:13:11 -0000
- To: xmlschema-dev@w3.org
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
Received on Thursday, 31 January 2008 11:58:38 UTC