[regrep] Re: Core Components Specifications

[Matthew MacKenzie <matt@xmlglobal.com>]

I think that UML would be a great way to model core components if it 
were possible to create a new diagram type that is derived from the 
Class diagram.

A Class Diagram can have deep nesting and maintain relationships between 
both parents and children in the nested structure.  Relationships can 
also be represented between classes not existing in the same package.  
If one were careful, I expect a set of core component instances could be 
generated from a java package that had been modeled using a tool such as 
Together Control Center (www.togethersoft.com).  Together can already 
export a model as a DTD, so I imagine it would be possible to output XML 
that conforms to a CRI spec.  By defining a new diagram type, tool 
vendors could extend modeling tools to reflect the actual structure and 
content model of core components.

All the above aside, I firmly believe that we need both a way to model 
these things that is business analyst friendly, AND and easy to parse 
XML representation.  All of this bickering over which of the two 
components should prevail is ridiculous.

Regards,

Matthew MacKenzie
VP R&D - XML Global


On Monday, January 28, 2002, at 07:26  AM, Sandy Klausner wrote:

> Speaking of starting places, this thread has surfaced a fundamental 
> issue. Both XML and UML appear to have limitations in meeting emerging 
> net-centric computing requirements. Why must we insist on using 
> substrate technologies that were never conceived to deal with these 
> demanding requirements? Can you imagine Lexus engineers insisting on 
> reusing a '56' Chevy chassis for a new SC 430. Let's face the music, 
> XML was derived as a simplified SGML which itself never addressed 
> several fundamental modeling issues. As a unstructured, 
> document-centric model, it was never intended to deal with structured 
> data. On the other hand, UML was derived from CASE over a decade ago to 
> address structural modeling. It borrowed heavily from structured 
> techniques and added a thin object semantic layer and engaging graphic 
> syntax in a most primitive fashion. As far as alignment with XML, it 
> does not have an elegant way to graphically model deeply nested 
> constructs. Like CASE, UML never addressed the issue of how to 
> effectively integrate a graphic model with either a structural (like 
> XML) or behavioral (like Java) implementation to provide true 
> round-trip engineering. Therefore, a UML practitioner must maintain 
> discrete graphic and text representations, thus greatly increasing 
> system complexity, lowering reuse, and increasing the difficulty of 
> developing core components.
>
> We must fundamentally address this system complexity management issue 
> if there is any hope of creating a scalable set of 'core components' 
> suitable as a global substrate to create large-scale electronic 
> commerce. It appears that an executable design medium could address 
> many of these incompatibility challenges to create a scalable 
> technology usable by both domain experts as well as software 
> developers. Is there anyone listening on this thread interested in 
> exploring effective solutions to this most fundamental issue?
>
> Sandy Klausner
> 408.867.1100
>
> > From: Philip Goatly <philip.goatly@bolero.net>
> > Organization: Bolero.net
> > Reply-To: Philip Goatly <philip.goatly@bolero.net>
> > Date: Mon, 28 Jan 2002 14:07:31 +0000
> > To: bhaugen <linkage@interaccess.com>, David RR Webber - XMLGlobal
> > <Gnosis_@compuserve.com>
> > Cc: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>, "''Ebtwg-Ccs (list)' '"
> > <ebtwg-ccs@lists.ebtwg.org>, "''eBTWG (list)' '" 
> <ebtwg@lists.ebtwg.org>,
> > 'Hermes Hartmut ' <Hartmut.Hermes@MCH11.siemens.de>, 'OASIS Registry 
> List '
> > <regrep@lists.oasis-open.org>
> > Subject: Re: Core Components Specifications
> > Resent-From: <klausner@cubicon.com>
> > Resent-To: sklausner11@attbi.com
> > Resent-Date: Mon, 28 Jan 102 09:09:22 EDT
> >
> > Mr Haugen,
> >
> > I agree entirely - It  is necessary to separate the 'model' from the
> > implementation and to derive perhaps many implementations - from the 
> model.
> > If the model is  un-ambiguous the 'rules' by which the implementation 
> may be
> > derived are capable of being programmed. It follows therefore that the
> > implementation has the same relationship to
> > the model as, say the binary code of a program, has to the ASCII 
> source of
> > the program code.
> > I am not a great reader of the binary code of programs - but each to 
> his
> > own - I do however have some ability reading
> > ASCII code, which is much easier to understand.
> >
> > The model therefore should be the starting place. Then all artifacts
> > constructed from the model will be consistent.
> > If one starts with the artifacts, what will enforce consistency 
> between them
> > ? and which artifact should be the driver ?
> >
> >
> > My 2 pence worth
> >
> > Cheers, Phil
> > ----- Original Message -----
> > From: "bhaugen" <linkage@interaccess.com>
> > To: "David RR Webber - XMLGlobal" <Gnosis_@compuserve.com>
> > Cc: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>; "''Ebtwg-Ccs (list)' '"
> > <ebtwg-ccs@lists.ebtwg.org>; "''eBTWG (list)' '" 
> <ebtwg@lists.ebtwg.org>;
> > "'Hermes Hartmut '" <Hartmut.Hermes@MCH11.siemens.de>; "'OASIS 
> Registry List
> > '" <regrep@lists.oasis-open.org>
> > Sent: Monday, January 28, 2002 1:31 PM
> > Subject: Re: Core Components Specifications
> >
> >
> >> From: David RR Webber
> >>> Message text written by bhaugen
> >>>> Would it help to get out of these endless and fruitless
> >>>> argument loops to agree that:
> >>>> * UML is for models that are independent of
> >>>> implementation technology
> >>>> * XML is an implementation technology
> >>>> * People can work at whichever level
> >>>> is most appropriate for what they
> >>>> are trying to do
> >>
> >>> Exactly.  And trying to mandate one or the other is
> >>> equally illogical.
> >>
> >> Depends on what you're trying to do.
> >> James Clark, one of the founders of RELAX-NG
> >> which you consistently advocate, says:
> >>
> >> http://www.thaiopensource.com/relaxng/design.html
> >>
> >> "I would argue that trying to make an XML schema
> >> language also be a modeling language is not a good idea.
> >> An XML schema language has to be concerned with
> >> syntactic details, such as whether to use elements
> >> or attributes, which are irrelevant to the conceptual
> >> model. Instead, I believe it is better to use a standard
> >> modeling language such as UML, which provides full
> >> multiple inheritance, to do conceptual modeling,
> >> and then generate schemas and class definitions from
> >> the model"
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----------------------------------------------------------------
> >> To subscribe or unsubscribe from this elist use the subscription
> >> manager: <http://lists.ebtwg.org/ob/adm.pl>
> >>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebtwg.org/ob/adm.pl>
> >
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.