[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Schemas as interoperational interfaces - practical issues

• To: "'Blue Gecko'" <bluegecko@l...>,<xml-dev@l...>
• Subject: RE: Schemas as interoperational interfaces - practical issues
• From: "Michael Kay" <mike@s...>
• Date: Wed, 5 Oct 2005 09:51:22 +0100
• In-reply-to: <43438ABA.5030700@l...>
• Thread-index: AcXJhRpchKP0ZxR2TACKx0zxhbmbYgAA15rg

It's a classic situation: if you offer a service at a particular level of
abstraction, there will always be people who want to argue a case for going
in and accessing the underlying resources at a lower level of the software
(or hardware!) stack. Anyone with experience knows the long-term
disadvantages of breaking encapsulation in this way; but there are sometimes
pragmatic reasons for doing it anyway, and sometimes you just don't have
sufficient authority to stop people doing it even if the reasons are bad
ones.

There are cases where offering a service at the SQL level makes sense and
perhaps your colleague has experience of a system that worked successfully
at that level. The main thing is that you have a clear policy on the matter:
if the SQL level is an external interface then you are going to have to take
a lot more care over change control at that level of the system. What's
really bad is when clients use an interface that was intended to be internal
as if it were external.

Michael Kay
http://www.saxonica.com/  

> -----Original Message-----
> From: Blue Gecko [mailto:bluegecko@l...] 
> Sent: 05 October 2005 09:12
> To: xml-dev@l...
> Subject:  Schemas as interoperational interfaces - 
> practical issues
> 
> 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? ;-)
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 

• References:
  • Schemas as interoperational interfaces - practical issues
    • From: Blue Gecko <bluegecko@l...>

• Prev by Date: Schemas as interoperational interfaces - practical issues
• Next by Date: RE: Better design: "flatter is better" or "nesting is better" ?
• Previous by thread: Schemas as interoperational interfaces - practical issues
• Next by thread: RE: Better design: "flatter is better" or "nesting is better" ?
• Index(es):
  • Date
  • Thread