Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Schemas as interoperational interfaces - practical issues

From: Blue Gecko <bluegecko@------.-->
To: xml-dev@-----.---.---
Date: 10/5/2005 8:14:00 AM
Hello all,

I'm struggling against a colleague of mine who keeps reasoning (there 
are piles out there, you guess!) with the same unsane patterns so 
popular in the dark ages of commercial IT, when interoperability and 
shared standards were just an unattainable Holy Graal.

So, the document management application I maintain adopts an XML 
Schema-based interface to import customizable documents: the client 
application freely defines its types, pours them into an XSD file and my 
DM application reverberates such types in the database schema. I feel 
this smooth mapping just *elegant*, 'cause it keeps encapsulated the 
reciprocal behaviours avoiding desperate clashes between the actors.

The problem is that my colleague wants its business application to 
directly access my database schema (!!!) bypassing the XSD interface in 
order to handle the core database schema by itself! I think he's a crazy 
4GL old-style programmer, but trying to persuade him that such a 
strategy is perfectly nonsense he argued that his customers need to be 
able to change the schema so frequently as their dresses (?!).

I humbly believe that application data interfaces should be quite (UK 
meaning) stable and well designed to support extendibility/compatibility 
instead of broken revisions.

Can anyone save me from this tragi-comical situation?
Am I hallucinated or the task is sinking in the grimiest mud? ;-)


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent