Re: ebXML Entity Classes - Resend

[Martin Bryan <mtbryan@sgml.u-net.com>]

> A deficiency of the diagram is that it is not preceeded by higher level
> class diagrams.

It is, but these are defined in the business process model

> For example, in the diagram both
> "CoreComponentTypeDefinition" and "ApplicationComponent" express the same
> set of properties, which suggest they should share a common class.

They are a common class, but as they need to be managed separately they have
been separately named. I(Core components need to be formally registered via
an ebXML process, but applications components do not need formal
registration.

> Numerous
> other objects shown in this diagram express like properties.

But none share the same model.  In most cases they serve as "qualifiers" for
components when used in a specific context.

>  As a model for
> developing such diagrams, the R&R documents provide a much more organized
> top down multi-layer approach to metadata representation.

That's because they have totally generalized their model: we have
deliberately chosen not to generalize as this makes it impossible to
distinquish between the different management domains of core and non-core
functions.
>
> I do not recall seeing a "Registry and Repository model" for core
> components. It's not in my 15 February 2001 CC context document.

Thats because R&R have generalized to the extent of having only one type of
object, and fail to identify which ones are core and which are application
dependent.

> And R&R
> doesn't yet have the foggiest notion what a CC looks like!  We agree the
> CC's will be stored in the R&R, and yes, the R&R will handle the
ownership,
> version, etc stuff (in the Registry).  Please understand that doesn't mean
> the CC model should ignore these properties in its overall meta-metadata
> model.

But it does not need to record every point at which they are used.

Martin Bryan