[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: re Business Reqs paper
Terry,
We seem to be at cross-purposes here. There are TWO
repository efforts - the OASIS one, and the ebXML one.
They are not the same, that is very clear. So why are you
questioning if things are 'out of scope' when the ebXML scope
is yet to be determined?
I see ivory towers here, packed full of baggage looking for
a destination. The ebXML Repository is clearly a fresh start,
not a follow-on effort.
Now - the other image I see is the classic cartoon of a
room full of computer geeks, sat at computers, and the guy
in the business suit is walking out the door as he says:
"You folks keep on coding, while I go and find out what
the end-users want".
Hello - noone has yet determined EXACTLY what is needed
to deliver ebXML from the end-users stance (workable, usable, and
fit-to-business-purpose, and offering concrete business ROI).
Yet what I see is TONS of people rushing in offer code-this, and
code-that.
Scott Nieman is starting to walk down a better path with the use-cases,
but we need this much more clearly defined. We will also need to
wait some on parallel efforts in terms of messaging, trading partner
interactions and process control to full see how all this fits together
from the end-users perspective in a total, integrated, package.
Declaring anything 'out of scope' right now seems to be totally
premature, along with trying to force a technical solution ahead
of understanding the EDI business needs.
DW.
=========================================================
Message text written by Terry Allen
>
This all makes sense to me, too, but some items seem out
of scope.
| ebXML Registry and Repository
| Business Requirements : Draft Dated December 8, 1999
| Standards Development Workflow
|
| - The business would like to support legacy information,
| including historical
| EDI directories ( X12, UN/EDIFACT, etc. )
These relate to documents.
| - The business would like to be able to store a legacy
| data model (e.g., IDEF-1X) and retrieve it back out as
| a UML class diagram allowing them to further
| enhance the information within an object oriented paradigm.
This goes much further. Is it in scope to do it, or only
to consider it so we don't do something that might make it
impossible later?
| - The business would like to utilize existing software and
| standards that are already in place. (reuse-buy-build principle)
As much as is reasonable; taken absolutely that would tie us to
EDI.
| - The business would like to be able to interactively map
| internal application
| semantics to horizontal and vertical industry semantics
| (semantic equivalent mappings).
Requires expression of relationships within classification schemes.
| - The business would like to know in what context data is
| being used in the business process.
Good idea, but I don't see that as a requirement on a repository.
| - The business would like to avoid reinventing the wheel,
| by reusing parts within the repository to construct new
| file specifications.
Yes, this is the view of the repository as a development environment.
XML.org has the same view; the OASIS TC is specifying something that
deals with a more general case, but the same set of administrative
metadata should serve both.
| - The business would like the ability to request a change or
| enhancement to an artifact within the repository as a result
| of implementation issues.
This too may not be a requirement on a repository.
| - The business would like the ability to search for an item in
| the repository based, either an exactly match or similar
| (fuzzy) capabilities.
Requires expression of fuzzy relations in a classification scheme
(we can do that).
| - The business would like to be ensured that no one
| changes the information
| in the repository that is not authorized to do so.
|
| - The business would like to be ensured that no one sees
| information in the repository that is not authorized to see.
|
| - The business would like assign work items to others.
Definitely not a requirement on a repository.
| - The business would like to submit proposals for work
| items into the repository in any electronic format possible.
Okay, but if I'd kinda want proposals for work items to
be in a common format.
| - The business would like to know all the different
| specifications a particular data element is used in.
All the specs in that repository, that is.
| - The business would like to know all the vertical domains
| that a particular artifact (UML classes, XML declarations)
| is used in.
I think "data element concept" should be used here, not "artifact".
| - The business would like to be able to differentiate work
| in progress to that which is an actual standard.
|
| - The business would prefer names of items that are
| predictable, based on a formal scheme.
|
| - The business would prefer version identifiers that are
| predictable, based on a formal scheme.
|
| Application level Usage
|
| - The business would like a repository that is available
| on the Internet on a 24x7 basis
|
| - The business would like repository performance levels
| that support real-time interaction with business applications
|
| - The business would like to have dynamic mapping tools
| that automatically retrieve the most current file specification
| from a repository.
I think that can be done by supplying names for "the most recent
version" of things that also have names that include version numbers.
| - The business would like to immediately retrieve a file
| specification to understand how to correctly parse a file.
|
| - The business would like to immediately retrieve a file
| specification to understand how to write out a conformant file.
|
| - The business would like to know in what context data
| is being used in the business process.
|
| - The business would like to discover which trading partners
| are capable of
| engaging into a given electronic business transaction.
By asking them? this seems to be outside the repository, too.
| - The business would like to know which trading partners
| provide certain products and services.
Ditto. This information might be stored in XML documents that
go in a repository, but otherwise it seems like directory stuff.
| - The business would like to know what networking schemes
| must be used to physically communicate with a trading partner.
Certainly outside scope for a repository.
| - The business would like to publish their e-business
| capabilities / profiles within the registry to facilitate
| discovery by intelligent information agents.
I think that's a directory. I know some folks call it a
repository (including some at C1), but it's a different case
from the development-environment repository. Which is not to
say it can't be constructed the same way.
regards, Terry
----------------------- Internet Header --------------------------------
Sender: owner-ebxml-regrep@lists.oasis-open.org
Received: from lists.unicomp.net (lists.unicomp.net [209.41.64.203])
by spdmgaaf.compuserve.com (8.9.3/8.9.3/SUN-1.7) with ESMTP id
QAA10163
for <Gnosis_@compuserve.com>; Thu, 23 Dec 1999 16:42:13 -0500 (EST)
Received: (from majordomo@localhost)
by lists.unicomp.net (8.8.7/8.8.7) id QAA10542
for ebxml-regrep-out; Thu, 23 Dec 1999 16:34:29 -0600
X-Authentication-Warning: lists.unicomp.net: majordomo set sender to
owner-ebxml-regrep@lists.oasis-open.org using -f
Received: from marine.sonic.net (marine.sonic.net [208.201.224.37])
by lists.unicomp.net (8.8.7/8.8.7) with SMTP id QAA10539
for <ebxml-regrep@lists.oasis-open.org>; Thu, 23 Dec 1999 16:34:28
-0600
Received: (qmail 16488 invoked from network); 23 Dec 1999 21:41:33 -0000
Received: from prop.sonic.net (208.201.224.193)
by marine.sonic.net with SMTP; 23 Dec 1999 21:41:33 -0000
Received: from bolt.sonic.net (tallen@bolt [208.201.224.36])
by prop.sonic.net (8.8.8/8.8.5) with ESMTP id NAA21354
for <ebxml-regrep@lists.oasis-open.org>; Thu, 23 Dec 1999 13:41:33
-0800
X-envelope-info: <tallen@bolt.sonic.net>
Received: (from tallen@localhost) by bolt.sonic.net (8.8.8/8.7.3) id
NAA01975 for ebxml-regrep@lists.oasis-open.org; Thu, 23 Dec 1999 13:41:32
-0800
Date: Thu, 23 Dec 1999 13:41:32 -0800
From: Terry Allen <tallen@sonic.net>
Message-Id: <199912232141.NAA01975@bolt.sonic.net>
To: ebxml-regrep@lists.oasis-open.org
Subject: re Business Reqs paper
Sender: owner-ebxml-regrep@lists.oasis-open.org
Precedence: bulk
<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC