Re: ebXML Entity Classes - Resend

[Farrukh Najmi <najmi@east.sun.com>]

I have not followed this discussion closely but I wanted to let the CC group be
aware of a new development in RR. We are working on a proposal to include a
collection of extensible attributes (SO defined attributes) called slots in the
registry metadata class now called RegistryEntry (was ManagedObject). This may
be useful in the CC work as it allows CC to define custom metadata attributes
for their content. The details will be in the next rev of the spec sometime this
week. This message is just an FYI in case it is relevant information.

Chris Nelson wrote:

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

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard