[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