RE: ebXML Entity Classes - Resend

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Chris,

Yes, the diagram you refer to (on page 8) is a start at defining the
metadata structure.  (Sure is in small print though!)
I was familiar with the diagram when I started this discussion thread.  In
fact, it was this diagram which led me to start this thread.  The
spreadsheets represent bottom up thought.  The diagram represents higher
level thought applying lessons learned from the bottom up exercise.
Now its time to begin at the highest level and work all the way down to the
bottom. 

A deficiency of the diagram is that it is not preceeded by higher level
class diagrams.  For example, in the diagram both
"CoreComponentTypeDefinition" and "ApplicationComponent" express the same
set of properties, which suggest they should share a common class.  Numerous
other objects shown in this diagram express like properties.  As a model for
developing such diagrams, the R&R documents provide a much more organized
top down multi-layer approach to metadata representation.  

I do not recall seeing a "Registry and Repository model" for core
components. It's not in my 15 February 2001 CC context document.  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.  

The Repository is just a storage device to the Registry.  It is up to the
entity requesting storage of data in the R&R to define the syntax and
content that goes in the Repository.  And the UML diagram you refer to is a
step in that direction.  

I certainly expect that the R&R will store an assortment of objects of
dissimilar type.  It would make no sense to generate an XML Schema for a
given business transacton every time someone needed to retrieve the schema.
Nor will every XML Schema be automatically generated.  
And if it is automatically generated, it won't be R&R specific software that
does the generation.



-----Original Message-----
From: Chris Nelson [mailto:chris@cnelson.demon.co.uk]
Sent: Saturday, March 03, 2001 5:07 AM
To: ebxml-core@lists.ebxml.org
Subject: Re: ebXML Entity Classes - Resend


I reply to the original e-mail from Robert Miller which starts

> I've heard from two individuals that my attachment got mangled.  As it was
a
> very short attachment, I've converted it to inline text (losing some
> editting structure in the process - sigh):
>
> > Some thoughts on ebXML Classes
> >
> > Submitted by Bob Miller
> > Introduction

There is a core component model, developed intitally at Tokyo and revised in
Vancouver.  It can be found in the Core component context document.

There is also a Registry and respository model - all core component metadata
will be stored in a registry.

We took out all ownership, version etc. metadata out of the core component
model, as this is handled by the registry.  The rest of the model covers the
points made.  Or, at least it should.  If there is something missing then we
need to know.

A decision needs to be made on the format of the interface to store these
core component classes -
define XML specifications, choose XMI etc.  It does not really
matter how they are stored, as long as the interface is common.  The
Registry team have/are building an XML spec for the registry side (for the
Registered Item), and the core component team need to specify similar XML
for the actual core component definition (i.e. the Repository Content).

The actual client interface to the registry needs to be aware of both the
registry XML spec and the core component XML spec.  In this way, a user can
submit, browse etc. the core components and is unaware that when asked for
organisation details, it is actually the registry metadata that is being
requested, and when asked for a min/max occurs for a core component type,
that it is from the core component model.

There reamins, however, a fundamental question.  Where is the XML for the
document? Is ii made up from XML fragments in core components, or is is
built from the final document as defined by the core component model.  If
the latter, what are the rules for building it.  There was a lot of debate
in the early days on a rule based system for doing this (e.g. XMI).  But
this seems to have gone away.  I feel that if this question is answered (and
perhaps the XML experts already have the answer) then we can all better
understand the role of the core component model and how we derive XML.

From my limited knowledge I would hazard a guess that the
registry/repository hold both the metadata that defines the structure, rules
to be followed when creating the structures (e.g. include/exclude, change
data type) etc., and the resulting XML from applying this metadata
definition - either at the fragment level (e.g. one component) or at the
document level only.  But that's just a guess.


Chris Nelson
Dimension EDI Ltd.