ebxml-regrep message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Rawlins Comments on R&R Info Model and Services Spec


Mike, I am sorry that you don't understand the architecture, or the business
need for low cost or FREE software that allows B2B integration into their
business applications.  The inclusion of the software component reference is
trivial by nature, and I don't feel it is a major concern.  I need to wear
the TMWG hat on a regular basis, as it is a basis for the initiation of the
collaboration between OASIS and UN/CEFACT.  If we missed something in the
requirements, we failed to document them -- even though I felt we did in
Orlando, but perhaps it was removed and I did not catch it.   

As far as Core Components are concerned, we will continue to work with them
to ensure the RIM satisfies their needs.  It is a critical piece of the
ebXML work.  In Tokyo, we looked at their models, and modified the RIM to
handle context and mapped many of their concepts to the ManagedObject
concept (which will change terminology as a result of the Vancouver meeting
I understand).  CC did not have available information on the core components
at the time we developed the specification, despite our requests for this
nine months ago.  We would be glad to incorporate what is relevent to the
RIM.

Regards,

Scott

-----Original Message-----
From: Mike Rawlins
To: Nieman, Scott
Cc: 'ebxml-regrep@lists.ebxml.org'
Sent: 2/15/01 5:37 PM
Subject: Re: Rawlins Comments on R&R Info Model and Services Spec

Scott,

Even if I accepted the feasibility of your architectural vision (which
I don't), we are still left with three major issues:

1)  Feature creep - Your references to X12X/SITG and UN/CEFACT/TMWG in
this
discussion are totally irrelevant.  The governing authority is the ebXML
Requirements Spec, which has no mention of any such requirements in the
section
detailing R&R requirements.  The fact that you did talk about them in
your
business domain document, where I also objected to them,  still does not
validate the requirements since that document was never voted on by the
full
membership.  If I were in QRT, I would recommend rejecting the RIM on
this
basis.

2)  Appropriate forum - Hosting software components in the registry
implies to
me that they will be sold - either on a one-by-one basis or by
subscription.  I
have no problem with some interested group of vendors extending the R&R
spec to
provide such functionality, but I think it is inappropriate for us in
this forum
to be doing the design work for what is essentially a for-profit use of
the
registry.  I will not donate any of my time to such an effort, even for
review.

3)  Priorities - Even if our consensus holds against my first two points
here,
there is still a significant issue in that major required functionality,
such as
full support for ebXML Core Components, is still not achieved.  If we
are to
succeed in this enterprise we must fully support the core features of
ebXML
before we work on nice-to-haves.

I will vote against any R&R specifications which do not adequately
support our
core features, especially if they also contain out of scope
functionality.

Cheers,


"Nieman, Scott" wrote:

> >>Line Range: 399-402, table
> Type: Technical
> Issue or Rationale: No valid case for including support for
> Object_Type_Software_Component in this specification
> Suggested Change: Remove
>
> Mike, I will speak wearing two hats to address your comment.  Both
X12X/SITG
> and UN/CEFACT/TMWG recognized the need for the inclusion of software
> components.  A scenario by definition is a path through a use case, or
more
> specifically as the use case is realized, a path through a state
machine.  A
> software component that implements this state machine when operated
with the
> ebXML Messaging Service allows the ability to integrate XML messages
> directly into business applications; including custom applications,
> commercial off the shelf packages, and legacy apps.  Integration is
the key
> rational for this statement, and it does not have to be done with an
> expensive tool like traditional EDI mapping tools.  It ties back to
the
> basic business requirements, of creating low cost solutions for the
SME.
>
> I have sent several messages to various listservs on this topic.
While one
> ebXML Registry stores specifications, another may store company
profiles,
> and another may store software components that bridge between business
> applications and XML interfaces.  Some of this is alluded to in the TA
spec
> (lines 303-304 and 324-326).  So, as a trading partner discovers
another
> trading partner (its capabilities, its business processes ->
represented as
> scenarios) it may also discover that software component is available
at the
> software component registry (through an association to an external
object)
> that allows it to interact with the discovered trading partner for the
> scenario in their CPP.    In the case of the commerical off the shelf
> package, such as QuickBooks, this software component would be provided
by
> the software vendor (Quicken or its assigns).  Its no different than
your
> browser downloading a Shockwave plug-in, installing, and wa-la, ready
for
> prime time (in this case B2B).
>
> So help me out, why is this NOT a valid case?
>
> I would like to stress that software component registries do already
exist,
> and could be adapted to this business case.
> http://www.componentregistry.com/
>
> Regards,
>
> Scott
>
> -----Original Message-----
> From: Mike Rawlins [mailto:rawlins@metronet.com]
> Sent: Sunday, February 11, 2001 2:07 PM
> To: ebxml-regrep@lists.ebxml.org
> Subject: Rawlins Comments on R&R Info Model and Services Spec
>
> Please find my comments attached below.
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC