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

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Duanne,

I will try and contribute some partial responses to the questions below:

Duane Nickull wrote:

> 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?

The Core Component is a respository item represented by an ExtrinsicObject
instance n RIM. The ObjectRef will reference the UUID of the ExtrinsicObject
for the Core Component using its id attribute (see rim.xsd fro schema
details).

>
>
> 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.

The normalized syntax is the UUID based reference. Other means are to
associate
ExternalIdentifiers to the ExtrinsicObject which may include a URN.

Parsing the core component itself will using the mimeType attribute of the
ExtrinsicObject
to know that it is text/xml etc.. Further it may involve knowing which
Schema document
governs the syntax of the Core Component. I would encourage CC group to
define
normatively that there MUST be an association between a Core Component and
the schemas
that it uses with the Rgeistry-defined assocuationType of  "SchemaFor" or
some other CC defined
associationType. This will enable parsing of the CC.

>
>
> 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.

Again Registry Associations will provide those easily traversable links.
Tools such as a
generic registry browser or a specialized CC browser could navigate these
association links.

>
>
> 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.

Again I assume a well design XML schema would catch many such problems right
in the schema aware XML parser.

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

Or simply using an XSLT style sheet that is also linked with the CC using
another Association with a CC defined
associationType (transformerFor?).

>
>
> 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).
>

By now I have lost what *IT* is :-) Sorry if I am off-topic. I think that
the fact that we are talking about RR and CC in the same thread is a huge
step forward. We need much catching up and understanding the water that has
flowed under the proverbial bridge.

>
> 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/
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh