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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: re Business Reqs paper



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC