Re: [xml-dev] XML schema Management

["Fraser Goffin" <goffinf@googlemail.com>]

How interesting. I also work for a large financial services
institution and we use both ACORD and the UK equivalent Polaris. We
are also creating an internal data interchange standard which will be
based in our case on Polaris which we also need to extend to
accomodate 'internal' data. We also need to accomodate ACORD since it
is used by our main operational Policy/Claims application.

We have a number of objectives. One is to encourage a high degree of
consistency in the definition and use of core business entities across
all occurences of their use in transaction specific schemata. This
leads on to another key requirement which is to do with managing
change, both 'breaking' (major) and 'non breaking' (minor) revisions.
Obviously changes to core entities (common aggregations) have the
potential to impact many schema, but our experience shows us that a
'big bang' approach to aligning all uses of a 'type' is just not
acheivable (from a practicality perspective). So, how to enable
flexibility in the data model and consistency and [relative]
synchronisation in its use ??

I have been following the progress of UBL 2 and in particular the
proposed extensibility model and approach to code lists. This has been
informative and may be something that we can use (at present the
Polaris standard has no extensibility mechanism whatsoever).

I would be very interested in hearing more about your involvement with
ACORD since, as I'm sure you know, there has been a lot of talk over a
long period about 'harmonisation' of ACORD and Polaris (although I
very much doubt this will ever happen).

The question of whether its better to start with a [partial] business
data domain model and from this derive the message/service data model
or vice-versa is an interesting one. We certainly need to be able to
create business services at a speed that precludes the construction of
a complete enterprise data model, but nonetheless, I think there also
needs to be some 'top down' work to ensure that as the business domain
model is 'fleshed out' and starts to meet other parts which have been
defined and populated by other service delivery projects, that the
pieces have some likelihood of meshing.

Regards

Fraser.

On 08/09/06, Danny Vint <dvint@dvint.com> wrote:
>
> 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/
> >
> >
>