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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC