Re: ebXML Entity Classes - Resend

[Chris Nelson <chris@cnelson.demon.co.uk>]

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.