Re: What do people really expect from ebXML? - Is CC really a setofLegos?

[Philip Goatly <philip.goatly@bolero.net>]

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.html, 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
>