RE: What do people really expect from ebXML? - Is CC really a set ofLegos?

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

It's always nice to time travel - in this case back 15 years to when OO went
mainstream in programming.  This same argument was had there.  Top down
analysis works well for specific problems but results in solutions that are
hard to generalize/extend.  Bottom up analysis builds extensible structures,
but is not always ideal for any particular application.  Once people stopped
shouting, the answer was obvious - exclusive or's rarely make sense.  One
should proceed iteratively, and do both at once.  If one proceeds
iteratively, then one can recalibrate both ends of the tunnel numerous times
- unlike the physical world.

But a far better analogy is assembling machines from parts.  We wish to be
able to reuse the parts in a variety of similar machines - in which case
it's better to use a little glue here and there, then to always need to
rebuild from scratch because the parts you created for the last machine
can't be transplanted.

Matthew

> -----Original Message-----
> From: Philip Goatly [mailto:philip.goatly@bolero.net]
> Sent: Tuesday, May 01, 2001 12:58 AM
> To: Gregory, Arofan; 'William J. Kammerer'; ebXML Core
> Cc: Peter Guldentops; Zahida Christie; fray.gill@bolero.net; gavan
> haughey; michael.metivier@bolero.net; kara.wales@bolero.Net
> Subject: Re: What do people really expect from ebXML? - Is CC really a
> setof Legos?
> 
> 
> Hi Folks,
> 
>     I believe that a consideration of what data is essential in all
> transactions i.e what cannot be left out in any transaction( 
> as defined as a
> transaction in business terms) allows one to model a top down 
> structure.
> Since these pieces of data are 'essential' then they must always be
> processed. It follows therefore that when one starts with 
> this scenario,
> with the 'top level data' and the 'top level processes' the data and
> processes are intrisically bound together.The top levels can then be
> expanded to more detail.
> 
>     If one builds processes top down, and the data bottom up, 
> yes, there is
> a problem since it is like trying to construct a tunnel from 
> 2 different
> ends, and since at the start it is difficult to ascertain the 
> middle point -
> or even the direction - there is little likelihood that they 
> will meet. Data
> and processes will be disjoint no matter how much binding 
> glue one attempts
> to apply to paper over the cracks.
> 
> Well there's my 2 pence worth.
> 
> 
> Cheers, Phil
> 
> P.S. UML is not so bad for modeling data - it just depends 
> how you do it ;-)
> ----- Original Message -----
> From: "Gregory, Arofan" <arofan.gregory@commerceone.com>
> To: "'William J. Kammerer'" <wkammerer@foresightcorp.com>; 
> "ebXML Core"
> <ebxml-core@lists.ebxml.org>
> Sent: Monday, April 30, 2001 8:17 PM
> Subject: RE: What do people really expect from ebXML? - Is CC 
> really a set
> of Legos?
> 
> 
> > Folks:
> >
> > This is an interesting dicsussion of "top-down" versus 
> "bottom-up", and I
> > think William has a valid point - no amount of "top-down" 
> analysis - short
> > of modelling each and every back-office system in UML - 
> will give you the
> > full data set needed to determine the exact details of the payload.
> >
> > Obviously, we will be modelling processes - and not 
> detailed processing -
> > according to the BP work, and these with a focus on the 
> exchange between
> > enterprises.
> >
> > There is still a need to agree on the basic payload, and I 
> would argue
> that,
> > while consistent top-down design is highly desirable, it is not the
> critical
> > lack that we have. The problem we have is understanding the 
> requirements
> for
> > where CC and BP meet, so that "top-down" design can be 
> intelligently done,
> > and then work can be carried on within that framework for 
> the bottom up.
> >
> > I would argue that this is how we fill the bits in the 
> middle that connect
> > the core components (aka "legos", except that my personal 
> legos can be
> > turned into programmable robots that treat each other in a predatory
> > fashion, not what was intended by the use of the name, I 
> don't think...)
> > with the business process.
> >
> > I firmly believe that process-building, UML-based 
> interfaces can be made
> to
> > produce good documents. What is needed is a clearer 
> definition of where
> the
> > UML process modelling stops, and where the "payload" 
> begins. Otherwise,
> you
> > end up building your documents in all of their grisly detail as UML
> models,
> > which is a nightmare activity that should be experienced 
> before it is
> > advocated. There are better modelling methodologies for the 
> details of
> > documents than UML, and have been for a long time. What is 
> wanted is an
> easy
> > way for a UML process tool to reference a set of existing 
> components,
> > indicate how they will need to be modified, and then carry 
> on. We need to
> > tie together the business process and the document design, 
> not simply
> > abandon the second for the first.
> >
> > In all examples of UML-based document generation tools I 
> have seen (not
> all,
> > I am sure), the binding between the process model and the document
> > definition describes lots of good "stuff" about how business data is
> > modelled in XML. I believe that this "binding" is maybe a 
> critical piece
> of
> > the standardization that needs to be done if such systems 
> are to work.
> This
> > is, in fact, at the heart of the work being done around 
> "context" in the
> CC
> > group!
> >
> > Cheers,
> >
> > Arofan Gregory
> >
> > -----Original Message-----
> > From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> > Sent: Monday, April 30, 2001 11:43 AM
> > To: ebXML Core
> > Subject: RE: What do people really expect from ebXML? - Is 
> CC really a
> > set of Legos?
> >
> >
> > Betty Harvey bemoaned the demise of the IETF DTD VCard 
> specification,
> > since having a standard for personal information would keep you from
> > having to fill in the same damn information over and over 
> again on web
> > forms.  Though VCard smacks of B2C, it does have some carryover into
> > ebXML I suppose, and I just wanted to remind Betty of the 
> W3C's Platform
> > for Privacy Preferences (P3P), at http://www.w3.org/P3P/, 
> which looks
> > like a successor to VCard.
> >
> > I previously brought P3P to our attention last month, at
> > 
> http://lists.ebxml.org/archives/ebxml-core/200103/msg00099.htm
l, to show
> that its Section 5.3.5.1 (Postal) describes a simple structure for
> postal mailing addresses - for consideration in modeling ebXML's own
> Address core component.  Of course, Mike Conroy also showed other
> examples from ERP file layouts giving simple address structures.  I
> wanna know what sort of "top-down" analysis starting with the business
> model gave us the "postal address.details" aggregate shown in Initial CC
> Structure v1-03.xls. Anybody??
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org