ebxml-architecture message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Questions from Brussels
- From: "Petit, John" <jpetit@kpmg.com>
- To: ebxml-architecture@oasis-open.org
- Date: Wed, 17 May 2000 18:31:00 -0400
What an excellent meeting that was! We were productive
during the day and sated by beer
at night (a rewarding combo!) However, at the end of the week in Brussels, there remained
several outstanding questions in my
mind. There are others,
but the following stick out. I know
that in the minds of many group
leaders, there are answers or
approached to these issues, but those solutions have yet to at be outlined. The issues I have
here are somewhat different, or perhaps worded differently, from our “outstanding issues” section of the
Architecture Doc. More than likely the
answers to these questions have been stated, or I missed them in the specs. If
anyone is inclined, I would appreciate a few answers to some of them.
Requirements
- Does the scope of ebXML
mean that we are defining a comprehensive and cohesive e-commerce system, or a
series of independent, non-interoperable systems. Are we leaving the ability
of interoperate at a global level off the
requirements doc? I got opinions on
both sides of this. The
requirements document is rather vague on this (and most other issues).
Business Process Methodology
- Are
these UML process descriptions required? Can a company participate in ebXML
without these UML process descriptions? Could XSL B2B stylesheets and rules be
enough? I talked with some people from the
BP group and there were varying answers.
- Are
we going to be defining a set of stereotype extensions to UML to accommodate
process?
Technical Architecture
- Many questions have
come up in the course of our sub-groups work over the past six months. Anders
made a good point in saying that these issues, which seem to be continually
swept under the rug, should be handled more formally and thoroughly. What is
happening with that?
- The global search mechanism is still undefined. How will such a global search work? How will users find particular
schemas to search upon? How will the
perform common core searches?
- How
will items in repositories be
updated when changes are made? What is the change mechanism?
- Should we not have more
UML designs in our document? Should these not form the basis of our
architecture? If so, we should have them now. Perhaps we should also follow
the Rational Method, as several other groups are doing.
- If
we are building this, or specing this, should we not follow the Rational
Process and develop the domain model and
a complete use case list for
requirements? So far we have not produced UML
models of the architecture. This seems remiss as UML is playing such a large
role in ebXML.
- What about Autosearch
GUI generation? I know that there will be some sort of facility to associate
metadata documents with DTDs and schemas. How will these extra metadata
documents be referenced or associated with the schema? Will this facility be
able to accommodate documents that allow search description. This is a
facility for agent control/both manual and programmatic. [NOTE: need to see
how this facility will work, then perhaps make a separate specification and
recommendation]
- I do not feel that
this is out of scope for ebXML. Human interface is critical to effectively
accessing the terabytes on information that ebXML will be dealing with. In
order to access this information easily, we must provide a path by which
schema authors can specify the interface that makes sense to accompany their
schema. Such specifications will allow the automatic generation of multiple
languages as well.
- If someone can tell
me that this is beyond the scope of ebXML, or not worth addressing, then
fine. If it has to be a separate specification, fine, but we should have the
facility to work with it.
- What about commercial
exchanges? This should at least be addressed by
example. What about other specs that should be
included? OFX etc.? covered and gone over in scope.
Core Components
- Will Core be defining a list of common business tags?
This seems a real opportunity missed if they do not. If it does not, ebXML
will not be able to perform cross schema searches on basic items such as price
and business category.
- Not
addressed yet is the mechanism whereby a global search system will identify
items in schemas that are called by attribute namespaces. This needs to be
addressed for inclusion in the Tech architecture.
Transport/Routing and Packaging
Registry and Repository
- What exactly are items
in the repository and items in the registry? Clearly binaries will not be indexed and searched
upon directly through ebXML. However, binary files will accompany XML
documents (gif, jpeg, moov, applet, etc.). This needs further
definition.
- Who
will control the registry of registries?
What sort of organization can run a registry?
- As
this is supposed to be egalitarian, there are limited costs involved in this
correct SO to RA?
- How
will the update of data be registered? What is the mechanism for this?
- What exactly is stored
in the registry? Will schemas and
categorizations be part of registries, or will this be left up to the whim of
the RA?
Technical Coordination
Cheers, John
Petit
KPMG
XMLfs Team
Office: 970 728
9468
Mobile: 312 961
8956
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC