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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Co-operating with Architectural Forms

[ Lists Home | Date Index | Thread Index ]

It would seem that would be of use in a design 
for a virtual data warehouse.  In essence, it 
is the contract for the backend systems to join.

len

-----Original Message-----
From: Steven R. Newcomb [mailto:srn@coolheads.com]

> How useful is that in the real world? That is, if
> company A defines one format for invoices and company
> B defines another format, what are the chances that
> these are (hierarchically) similar enough that I can
> define AFs to process them as a single format? My gut
> reaction is that this is unlikely.

Right, Ron.  The AF paradigm is not for everyone, and
it's not useful for every purpose.

AFs provide a way for Companies A and B to *cooperate*
with each other to maintain one or more common base
syntaxes that will permit them to interchange
information reliably, and point the finger of blame
when information interchange fails to occur, but
without giving up any sovereignty that they wish to
retain over their separate-but-derived syntaxes.

If A and B haven't chosen to cooperate (or, more
accurately, if they don't both happen to use (any of)
the same base architecture(s), for whatever reason),
AFs have nothing to offer.

The act of cooperating can have many benefits in
addition to the benefit of reliable information
interchange, while retaining local control of the
details.  AFs just provide a tangible, workable goal
for cooperative efforts that use syntax as the basis of
cooperation.  That's not an insignificant thing.




 

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

Copyright 2001 XML.org. This site is hosted by OASIS