RE: [xml-dev] XML schema Management

["Len Bullard" <cbullard@hiwaay.net>]

++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@dvint.com] 

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/
>
>