OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [regrep] Re: Core Components Specifications


Philip:

I think you have misunderstood my comments.  First of all - UML is
perfectly acceptable for modelling core components and we are all agreed
that the UMM is the single methodology to be used (hence the UML).  The
arguement is centered around "How do we express Core Components".  Many
believe that we have to have a "Syntax Neutral" representation core
components.  

Well, <newsFlash> as soon as anyone writes one single byte of data,
whether it be a binary representation or ASCII, there is now a syntax. 
This is unavoidable.  IMHO - here is the requirement:

"What we are *really* striving for is that the Core Components must be
capable of being expressed in many different syntaxes and not bound to
any one single syntax."

We should not be discussing UML vs. XML.  The Core Component is the core
component.  The UML and XML are merely two diffferent expressions of the
same artifact.

Philip Goatly wrote:
> So I guess you are stuck with UML, or UMM must become
> XML based :-)
>>>>>>>>

UMM is the methodology, UML is the syntax.  If you use Rational Rose as
many people do, the UML you see on the screen is being generated by
internal code.  Do not confuse the UML you see in the GUI with the
actual objects.  There is not UML to XML conversion process that takes
place inside.  WHat happens is the same internal structure that is used
to generate the UML is also used to generate the XML.  Two different
expressions of the same object.

Now - since we need at least ONE syntax, and since we need a syntax that
is capable of being transformed in order that a Core Component MAY be
expressed in other syntaxes (as per our requirement to not be bound to
any one syntax), then I  would vote for an XML expression of the core
component.  The XML can be parsed by both a machine and a human, can
contain links to other expressions (such as the UML, although the
association can be accomplished via the RIM) and has the distinct
advantage of being supported by standardized parsers.

The other alternatives are that we only have some XML metadata in the
RIM that points at a UML diagram (Notice that the XML metadata produced
by the RIM is also merely an expression of the actual internal item from
the Regsitry Information Model).  This approach is very bad IMO and will
lead us away form our goal of interoperability.   The problems one could
easily encounter with improper data serialization and lack of
application parsing ability despite someone like Frank VD constraining
the rules for UML to XML conversions.

Duane Nickull 

>    No matter what one is doing one has a model in one's head. Telepathy is
> not a very good way of communicating it,
>    neither is speech. The formalisation of the model on 'paper/screen/
> etc.helps to communicate the design and intention.
>   A picture is worth a thousand lines of XML.
> 
>    One should not assume that only the artifact to be produced from a UML
> model will be XML - a UML model is
>    sufficiently  generic as to be able to produce - Java, C++, Smalltalk
> CORBA, IDL, Databases Relational or otherwise.
>    Methods may be defined Use cases, Activity & State etc. In fact it
> follows an 'OO' paradigm. XML of itself does not.
> 
>     XML is just one possible implementation. However if the only tool you
> have is a hammer to whole world looks like a
>    nail. i.e If you only know XML ..... :-)
> 
>    One must not ignore either the other intiatives in s/w enginerring such
> as MDA (Model Driven Architecture) which is being
>     promoted by the OMG and is well received.
> 
>    I urge you to think bigger and wider than XML.
> 
>    my 2p
> 
> Cheers, Phil Goatly
> 
> ----- Original Message -----
> From: "Duane Nickull" <duane@xmlglobal.com>
> To: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
> Cc: "'David RR Webber - XMLGlobal '" <Gnosis_@compuserve.com>; "'Hermes
> Hartmut '" <Hartmut.Hermes@MCH11.siemens.de>; "'OASIS Registry List '"
> <regrep@lists.oasis-open.org>; "''Ebtwg-Ccs (list)' '"
> <ebtwg-ccs@lists.ebtwg.org>; "''eBTWG (list)' '" <ebtwg@lists.ebtwg.org>
> Sent: Monday, February 11, 2002 11:02 PM
> Subject: Re: Core Components Specifications
> 
> >
> >
> > > "CRAWFORD, Mark" wrote:
> > >
> > > There is nothing in the CC spec that violates the requirements
> > > document.  Storage of CCs as UML defined objects is in keeping with
> > > the ebXML architecture document, and provides a much cleaner way to
> > > support OO, XML, and EDI instantiations.
> > >>>>>>>>
> > Mark et al:
> >
> > Conceptually, we should not be talking about UML to XML conversions.
> > Try to think of a Core Component as an artifact which can have UML or
> > XML expressions of itself.  They are two different presentations of the
> > same thing, not two different things.
> >
> > > BTW, if you really want syntax neutral representations, then XML
> > > doesn't cut it.  It is as syntax specific as UML.  Lets use ASCII text
> > > descriptions.
> > >>>>>>>>>>>>
> > Last time I looked, ASCII is not considered 100% syntax neutral either.
> > :)
> >
> > We have to have at least one default syntax for expression.  UML is fine
> > but XML does have some advantages.
> >
> > Many people assume that we don't need XML becuase they have the UML.
> > XML can be parsed by either a Human OR an application.  The same is not
> > true for UML.  Before you rush to type a rebuttal to this email, becuase
> > Rational Rose can generate code from UML,  examine the facts behind this
> > easily misinterpretted phenomena:
> >
> > When people view the UML in Rose or other tools, they don't often
> > realize that the UML they see is being internally built from XML (XMI in
> > some cases) or some other internal, structured code.  The internal code
> > structure powers the presentation of the UML, not the other way around.
> > Many simply misinterpret the GUI rendition as the actual object
> > (artifact).
> >
> > Since an XML file, if properly structured and robust enough, can be used
> > as the source to automatically build a UML presentation, and the other
> > way around is not true (binary UML to XML), I would highly favour using
> > XML as the default syntax.  XML can be easily transformed into many
> > other graphical and non graphical presentations as well.  Since at least
> > one structured (normalized rendition) is probably going to be requested
> > by those who are writing software for Design Time, I strongly suggest
> > that having a default XML structure for Core Components as the default
> > presentation syntax.
> >
> > My $0.02 worth.
> >
> > Duane Nickull
> >
> > --
> > CTO, XML Global Technologies
> > ****************************
> > Transformation - http://www.xmlglobal.com/prod/foundation/
> > ebXML Central - http://www.xmlglobal.com/prod/central/
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebtwg.org/ob/adm.pl>
> >

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC