Re: CC model

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

Robert,
Sorry for the delay in replying but my day job got in the way.

You make some valid comments which can only really be answered by deciding
what the core compoent model is meant to do.

In Tokyo, it was developed so that it could be put into the BP model.  In
fact, we did start to merge it at an inter sessional meeting in December in
London.

Then came Vacouver, where we found that the BP model was stand alone, the BP
rep. to the CC modelling team seemed to have disappeared and the CC idea of
how to describe a core component had moved on so the model had to be
changed.

Despite the numbers of people in CC there has never been a CC model group
per se, the modelling activity was tacked on to the Context group.  And with
just me as the UML "expert", this part of the activity has never had the
luxury of expertise or time that, for instance, the BP or the R&R group have
had.

Having said that, we need to decide what is the purpose of the model.  At
present, it is not so that someone can design and develop a core component
search, retrieval, and submission software engine without recourse to any
other specification (save TRP), such as the R&R specification would allow.
It is more what Martin Bryan has descibed.  It is a means to this end and
that is what was modelled.

Yes, I agree, there are some super classes that could be derived and this
did worry me somewhat.  However, to have put them in would have lost a lot
understanding by the CC people.

I am not saying that the model should not be changed, but I think there
needs to be a discussion first on what is the purpose of the model.  If it
is agreed that the model should be a specification of the interfaces to a
core component GUI (much like the R&R specification is today), then this
specification needs a lot of work.  However, it is possible using the
current CC (data) model and the R&R specification to specify an XML DTD that
is the actual implementation of such an interface (similar in concept to the
Registry DTD).  In fact, I think work is already underway on this.

Regards,
Chris Nelson
Dimension EDI

----- Original Message -----
From: "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>
To: <ebxml-core@lists.ebxml.org>
Sent: Monday, March 05, 2001 5:00 PM
Subject: RE: ebXML Entity Classes - Resend


> 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.
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org