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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: ebXML metamodel write-up

Actually, it is quite common that a customer will send you information in whatever their native 
format is and you try as best you can to figure out if you can map it to your internal system. The 
customer doesn't give a hoot. If you are missing some particular piece of information that is 
absolutely critical, then you would go back and ask the customer for it. We do several billion 
dollars worth of business that way every year. In or business processes, there is a big difference 
between a SalesOrder (info the customer sent us in their native format) and a SalesOrderConfirmed 
(which now has all the info you need so you can execute on it). In the end, the customer still 
doesn't know and doesn't care what we call the bits of info.



>On page 3 you wrote:
>>>>Independence of ebXML sub-metamodels
>Although clearly interrelated, the ebXML sub-metamodels are not tightly
>dependent on each other, and implementations of one can be very
>beneficial even in the absence of implementations of one or more of the
>others. <<<
>This is totally not true in the case of business process and business
>information.  The business process is dependent on being able to specify
>which core components (data Elements) are necessary for each party to a
>transaction to meet their respective legal and business requirements. 
>One cannot exist effectively without the other.  I can't just say "send
>some information to me" to place a Purchase Order.  It has to be
>specified "Please send me the thing I call address, the thing I call
>name, the thing I call telephone number etc.  Each of those objects has
>to also have the ability to be referenced via a repository so the sender
>also knows what they are.  The semantic reference from a repository
>dictates that the RegRep access process be integrally bound to
>potentially all transactions (at least in an abstract way - we are
>suggesting the use of a cache in the application to ease congestion to
>the repository query daemon).
>Also - A core component cannot be used effectively without a contextual
>guide to allow it to be instantiated correctly depending on the business
>process it is part of.  I can't just say Item <a> is equivalent to Item
><b> if there are ten places in each document where there are instances
>of those elements.  I need to know the context in which thety are being
>TRP as a stand alone - yes - excellent work being done there.  
>I look forward to seeing more on the subject of using the UML -> XML
>process for data elements and business processes.  This is an area we
>are concerned about.
>Duane Nickull

Peter Kacandes

Application Planning, Architecture & Strategy	phone number: 	X36529
WWOPS IT/Supply Chain Management		email:	peter.kacandes@ebay

[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