Re: [xml-dev] XML schema Management

[Jeff Rafter <lists@jeffrafter.com>]

In the MISMO space (Mortgage Industry Standards Maintenance 
Organization) in the US we encountered all of these same issues with 
varying degrees of success. The thing that seems most interesting in 
this discussion is looking at the changes over time for the industry:

Version 1) Produced Industry Sector DTDs (credit, 
automated-underwriting) etc. These were heavily ID/IDREF reliant. 
Essentially the hierarchy was secondary and the implicit graph of the 
data probably had precedence.

Little adoption.

Version 2) Recognized that the successful areas of the specifications 
were centered on specific transactions. Reworked all of the items into 
transaction specific (i.e. Request/Response) DTDs which included a 
static Envelope.

Heavy adoption continued again centered around the transactions.

Version 2.x) Constructed "Zero-Delta" Schemas (namespace-less) that 
would essentially return the same validation result that a DTD would for 
a given instance document (plus Datatype checking).

Version 3) Under development. As the user base increased, the desire to 
work on multiple transactions meant data repetition and small conflicts 
in structure. The group is now trying to build a multi-service set that 
is using hierarchy for repeated sets (as opposed to ID/IDREF). It is a 
hybrid approach, but conceptually there is still a strong notion of a graph.

Why? In the MISMO space there is a heavy mix of business and technical 
analysts. The business people are concerned with data points and their 
specificity-- not with structure. Because of this MISMO maintains a 
master list of data points (their Logical Data Dictionary). This list is 
global for all schemata (which would be their physical data dictionary, 
though this is never explicitly stated). The list owners are very strict 
when it comes to eliminating duplicate entries/concepts and maintaining 
backward compatibility.

Because of this the data can be placed into structures in regular ways 
(albeit sometimes confusing). What really needs to happen here is an 
RDF/OWL revolution where the various "parties" (broker, lender, client 
etc.) are RDF classes which have various properties hung on them. In 
most cases these classes (conceptually) are consistent across the 
transactions though they have more or less data at different points in 
the business lifecycle.

I wonder if this is something that manifests itself in ACORD or Polaris? 
If so, it would seem that some regular OWL<->XML Schema (or any 
schemata) class would be useful. For example, decorating an XML Schema 
with appinfo that signifies the relationship between a given property in 
RDF and a specific node in a grammar.

One could safely transition in and out of a resource description where 
(given the same tenets of backward compatibility) once could work in a 
more flexible model.

All the best,
Jeff

Fraser Goffin wrote:
> 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/
>> >
>> >
>>
>