For any particular interchange, you absolutely have to have to a  
common format.  My opinion is that it is extremely difficult,  
however, to find a format that will work across all interchanges.   
The reason is that an interchange is defined by both the information  
and reason for the exchange.  For example, one may have a universal  
model that describes an account.  The information interchanged about  
that account, and the semantics of how that account is described may  
vary based on how that account is used.  The representation of that  
account as part of an insurance transaction using ACORD XML for Life  
& Annuity may look very different that using that account for an  
equity transaction using FIXML.  This example is for illustration  
purposes, as I haven't actually checked the XML schemas, but it's  
pretty safe to say that there are common entities that both standards  
describe with their own nuances.  Both are widely accepted industry  
standards, so there is no right or wrong, only options.

When groups go out to define standards, it is important to take the  
context into account.  If you take a structural approach, you may  
wind up with a data representation that is structurally accurate, but  
not appropriate for any of the contexts in which that data is used.   
The good in that approach, however, is that you should have a model  
from which all of the context-specific models can be derived.

-tb

On Feb 20, 2006, at 1:11 PM, John, Anil wrote:

> Todd Biske wrote:
>
>> One thing that I advocate is for companies to embrace the fact
>> that there will be no one agreed format for all interchange.
>> There may be a universal model from which the actual interchange
>> models can be derived, but in terms of the messages flowing
>> at run time, multiple models with all of the
>> redundancies they bring will be the norm.
>
> Todd, could you elaborate a bit on this?  I am not sure that I am
> following you here. I thought that the point would be to have a common
> agreed upon format. Or is this more along the lines of Single
> Service/Multiple Contracts?
>
> Regards,
>
> - Anil
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply via email to