OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Data versioning strategy: address semantic, relationship,and syntactic changes?

Cox, Bruce wrote:

Greg, Roger, I hope you won’t mind if I give some of your interesting ideas a bit of a reality test.


In summary:

For us, changes are usually business driven and decided on cost, and, no, it makes little or no difference what kind of change it is.


In exhausting detail:

At the USPTO,  [a great wealth of experience is briskly presented]

So, for USPTO, it seems like change management is costly and, given the nature of the challenges, a "silver bullet" solution is almost certain not to exist.

I think the next big breakthroughs in software engineering that will help are a few years away but can be somewhat foreseen:  advances in (the practical application of) type theory will eventually be relevant.

A USPTO customer downloading XML files and feeding them into some process can be thought of as building a single statically typed program from various ambiguously typed parts -- the USPTOs services combined with the customer's own code.    That is, if we look only at the source code of the customer's programs, we can't infer a static type for them but if we get a complete type declaration for the USPTO input services, then the customer's programs' types can be inferred.

If we eventually standardize a representation for type signatures, then customers can abstract such representations away from their downstream software and "register" these type signatures with, say the USPTO.    The point of this is to help USPTO better estimate the costs of changes and to accelerate testing:   If a proposed change can be trivially type-checked against registered uses for the data or service, that can accelerate R&D for changes -- at least some kinds of costs of proposed changes can be spotted earlier than they would be without application models registered by customers.  Testing is similarly sped up: there's no need to run a test on a program that is known to not type check.

I'm not making any very specific commitment about the definition of "type" in this prediction :-)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS