Re: [regrep] Re: (CALL FOR COMMENTS) Core Components Specifications

[Duane Nickull <duane@xmlglobal.com>]

All:

I have been corrected by Farrkh on the current v 2.0 Registry
terminology. Thank you Farrukh.  Farrukh writes: "ManagedObject has been
renamed RegistryObject.To reference a RegistryObject you use an
<ObjectRef> element in the XML schema
for the registry."

I have ammended the question accordingly (below).  Farrukh - please let
me know if this is in line with current Registry terminology.

*******Request for Comments*******

The ebXML Registry contains an <ObjectReg> element in the Regsitry XML
Schema which points at the RegistryObject.

What is the <ObjectRef> Element going to point at when it references
a Core Component?

I aks this question becuase this needs to be answered BEFORE core
components can be implemented.  <QuantumJumpForwardInLogic> Since the
UN/CEFACT approval process calls for two independant implementations, 
this question must be answered and in the CC Specification.
</QuantumJumpForwardInLogic>.

To solve this question, I advocate that we first define all the
requirements for the answer.  Here is a starter list compiled from the
comments on this thread so far (from a programmatic AND business level):

1. Whatever the Registry references must not be bound to only being
expressed in one single syntax however, it MUST be expressed in at least
ONE syntax that is normalized. Otherwise, implementors will not know how
to parse the Core Component to present representations fo it to other
system actors, whether they be machine or human.

2. It should probably contain easily recognizable, traversable links to
the UML model representation of the Core Component AND have expandable
linking abilities to be capable of displaying itself in other formats
(in case something eventually supercedes UML, XML et al as per Lisa S's
comments). I would advocate that the linking mechanism be standardized.

3. It should be parsable by applications in a standardized manner.  This
is to avoid data serialization errors like misinterpretting a signed
integer as an unsigned interger.

4.  It should be easy to transform it via an application to other syntax
specific representations of the same object for re-use.

5.  It should ideally be either human parsable (readable) or it should
be easy to build an application to present a human being a link to a
human understandable representation of the Core Component (ie - text or
UML). 


These represent a good start to the requirements for this yet to be
determined artifact.

I would like to suggest that we review these and modify/add more
content.

Duane Nickull
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/