[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Why not object oriented?
I've been reading up (mostly white papers located on this site) about the current state of the ebXML standard. Something struck me as strange, one of the many goals of the standard is reusability / extendibility. We have available to us a technical way to meet these goals and many more, as you should have guessed from my header I'm referring to object oriented design. From what I can currently tell (I am a bit new to the ebXML world) one of the main challenges to this suggested (OOD) approach would be finding patterns already existing in the current business transaction formats (X12 / EDIFACT). Creating an inheritance tree from the thousands of predefined documents would be a nightmare. A simpler method would be to just have a document based objects, built with the core component (objects). If this were the case it would make conversion of documents much easier (cheaper) for both trading partners. You already have a few things that go along this thought process. The use of Core Components (A library of shared and reusable data items) all that needs to be added would be the inheritance extendibility support. Semantic Interoperability Document (SID) as defined in Document Assembly and Context Rules v1.04. From what I gather this is a way to compare two different but similar documents and perhaps cross map data. Would it be possible to use these as a way to keep track of the differences in document versions, perhaps even allowing for automatic update of trading partner mappings to the newest versions? Prompting only when required data has been added, or data has been removed from the new mapping. These (SID) documents could be used to polymorph data from one document version to another, this could even be applied to Core Components. Am I off base? When it comes down to it it's all about saving or making money. If the documents (and the common components that make them) were object oriented they would be cheaper to extend and support. Also if a small trading partner were unable to update their mappings (you really can't get them all to do it in the same day) of a specific document, polymorphism would take care of the translation (that is unless of course the new version had new requirements which were not met by prior versions). Perhaps this is beyond XML's original intent. Thanks, Ed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC