[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML schema Management
++1. That's what I did for I/LEADS for a couple of reasons. 1. I could query the software objects. They know best when they've been changed. 2. I could produce dozens of different reports on the master schema and create subschemas with just a bit of code and some queries. 3. I could update the text descriptions with ease. It is not that hard to build these tools and it is likely if you have any relational platform laying about that you already have these tools. A schema is after all, just a document. It is what consumes it that makes something different of it. len From: Danny Vint [mailto:dvint@d...] I'll second this. I used to work for ACORD the Insurance industry standards organization. We produced both a specification and an associated schema and DTDs beased upon that specification. This was/is a message oriented set of standards. Being an old SGML'r I was frustrated that they managed the DTD/schema design in a database instead of just hand coading or using something like Spy to create the schema directly. Over time it became apparent that the tradeoff was woth it. We were able to change schema "formats" relaitvely easily and maintaina a conistently organized schema from one release to the next. We put out 2 releases a year consisting of abou 2000 pages and a very large schema(s). We had one logical schema per spec, but we actually produced as a DTD, schema with and without a target namespace, and versions of the schema that had the code lists (enuemrated types) specified or not specified. This technique gave us a lot of freedom and abilty to react to changes requested by members. I'm now on the membership side of this effort and we want to use that standard internally and add our extensions where needed for the many different message that we need to support on top of these standard ones. I'm in the process of proposing that we need to build a similar system that we had at ACORD, but be able to import these updates from ACORD, manage our additions and new elements and hopefully build a set of hybrid documentation that shows our combined data in one location instead of two different documents. ..dan --------------------------------------------------------------------------- Danny Vint Specializing in Panoramic Images of California and the West http://www.dvint.com Voice:510:522-4703 FAX: 801-749-3229 On Fri, 8 Sep 2006, Michael Kay wrote: >> The problem : managing the production, versioning, >> consistency, .... of a large number of XML schema (typically >> for message based service interfaces) spawned from a core >> business domain data model. > > I've seen other people struggle with this problem. I haven't seen it solved, > but I've come to the conclusion that you need to put a lot of effort into > tooling, and I strongly suspect you are better off developing your own tools > in-house that are designed to your own specific requirements - though I > can't say that's based on detailed study of what the market can offer. > > I have seen an analagous problem solved, of managing hundreds of stylesheets > for processing different transactions in an online banking system. This was > done by devising a common high-level description of the various screens, and > generating the stylesheets from these master definitions, thus ensuring > consistency. I believe it should be possible to do the same thing for > controlling a large set of message schemas - but I haven't seen an existence > proof. > > Michael Kay > http://www.saxonica.com/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|