Re: [ubl-cmsc] Use Case Categories: Integration vs. Customization

["Eve L. Maler" <eve.maler@sun.com>]

I'm not sure I understand how the word "integration" fits in here; the 
description makes it sound more like what's often called schema 
"evolution", that is, deployment of new (presumably fixed/enhanced) 
versions of existing schemas, possibly with the same original context 
driver values.

If you mean evolution/versioning, it kind of comes back around to your 
original thoughts posted on the NDR list about how versioning might be just 
another context driver.  I certainly do think we should account for this in 
one or more use cases.  But from the experience of Arofan and others, it 
sounds like it's also quite common to develop a new document type from the 
same old piece-parts -- so common that they went to the trouble of 
developing a fairly sophisticated tool and GUI for doing it.  (I bet that 
"aggregation" is only a non-goal for now, and that it will get a promotion 
as soon as we've solved the other hard problems.)

         Eve

At 01:36 PM 12/6/01 -0600, Burcham, Bill wrote:
>It's my perception from mostly listening to our SC's over the past few weeks
>that the primary category of use case we've been implicitly working from is
>one where some user wants to craft a new kind of business document.  I'll
>call this category of use case "customization".  I haven't heard any
>discussion of what I feel is the far broader and more pertinent category of
>use case that I'll call "integration".  I just looked at out current list of
>use cases and verified that none of them talk about integration.
>
>My understanding of customization would yield a scenario like this.  A
>developer needs a brand new kind of business document for a brand new
>application (with a brand new trading partner).  That developer uses the UBL
>BIE's as a starting point, describes the deltas in terms of context _or_ XSD
>derivation, and then presses some sort of button to generate the new
>schemas.  Oh and since we aren't going to do "aggregation", the developer
>would then I guess write a new schema and import those generated
>(contextualized) BIE's in it.
>
>Taking a step backward -- I don't think that the value of our methodology
>(CM) has been proven for this kind of scenario.  I was hoping that the
>concrete example in the Extensions Position Paper would prove it, but that
>scenario hasn't shown up yet.  I guess that's not too suprising, since we
>are only beginning to develop use cases.  What might be surprising is that I
>don't believe there's any value we _could_ prove.  While I believe that
>certain users will derive documents from our BIE starting points, I believe
>to prove the value of UBL and more specifically CM we have to look at a
>different category of use.
>
>I think that by far the most important problem to solve is the "integration"
>problem.  I also feel that this is where we can actually prove some value to
>CM.  Further, I _suspect_ that this is the real problem way back in the
>primordial consciousness, that spawned CM.  That's why I find it so odd that
>no one has talked about it overtly.  Allow me...
>
>In integration problems there are always at least two parties.  As a
>simplifying assumption perhaps we could assume that the parties have systems
>in place communicating via (contextualized) UBL components.  Let's
>characterize that.  What then becomes interesting, to my mind, is what are
>the "change cases"?  This is what I'd like to hear from the domain experts.
>
>For instance, let's say that you've got a driving party (800 lb gorrila) and
>it decides to change some structure.  Question for business expert: what
>structure are they going to change?
>
>After that, it's either the case that the change is backward compatible or
>not.  In the case of a backward compatible change, participants will
>implement the change on different schedules.  What mechanisms shall we
>specify in support of that.  In the case where the change is not backward
>compatible: what mechanisms shall we specify to enforce that?
>
>Did I miss the memo wherein the integration problem is proved to simply be a
>special case of the customization problem?  If so, please point me to it and
>my life will get a lot simpler.
>
>My purpose in this rant is to try to narrow the scope of what were asking
>for when we go to the domain experts for use cases.  Again, I see great
>potential value in integration.  I'd like to focus our effort there.  And
>while it is a heckuva lot easier to understand, I see almost no potential
>value in customization.  Feels kind of like those keys and that street lamp.
>I look forward to hearing your views.
>
>-Bill
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com