[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep] Re: Core Components Specifications
If UML can be used to model objects, and objects can be generated from UML, and later marshalled and unmarshalled into XML, Phil, does your statement below still hold true? (By the way, I've done the above many times. XML allows for arbitrary tag names, attributes, and nesting. I doubt that there is anything in UML that can't be represented in good 'ole easy-to-parse XML) -Matt On Thursday, February 14, 2002, at 08:09 PM, Devendra Tripathi wrote: >> >> Folks, >> >> The reason for UML is the 'OO' dimenssion. >> >> Objects do not just contain data !!! >> >> They have State, and behaviour which can be expressed in UML - >> XML lacks >> robustness in this area :-) >> >> Cheers, Phil > > > > May be I am missing something here, but why a subelement of a XML > element > which can have N enumerated values, can not represent state of an > object. > > Regards, > Devendra Tripathi. > > >> ----- Original Message ----- >> From: "VANDAMME Frank" <frank.vandamme@swift.com> >> To: "Michael Adcock" <Michael.Adcock@apacs.org.uk> >> Cc: <MCRAWFORD@lmi.org>; <duane@xmlglobal.com>; >> <philip.goatly@bolero.net>; >> <Gnosis_@compuserve.com>; <ebtwg@lists.ebtwg.org>; >> <ebtwg-ccs@lists.ebtwg.org>; <regrep@lists.oasis-open.org>; >> <Hartmut.Hermes@MCH11.siemens.de> >> Sent: Tuesday, February 12, 2002 2:09 PM >> Subject: Re: Core Components Specifications >> >> >>> All, >>> >>> I agree with Mike and I honestly think that the discussion about UML >>> or >> XML (or any other format) is besides the point here. >>> >>> We need a repository that will contain all the relevant information >> regarding Core Components and the related concepts (like BIEs, >>> Context). The information that has been identified so far as being >> relevant is defined in the CC Technical Specification document. >>> >>> Core Components and the related concepts will be defined, used >> and reused >> during standards development. They will be referenced in >>> formal documents such as BPS and ASDOC. They will also be the basis >>> for >> the definition of business documents and for the physical >>> representation(s) in which these documents are ultimately >> transported on a >> physical network. They will be searched during recovery >>> and harmonisation activities. >>> >>> It's most unlikely that one single format will be sufficient to meet >>> all >> the above requirements. It is however important to have one >>> single basis from which all the other formats can be derived (and >> preferably in an automated way to avoid errors). My personal >>> preference (and the way we have implemented much of the above >> at SWIFT) is >> to start from a UML-repository and to generate databases, >>> reports and other formats from this UML-repository. It is a fact >>> however >> that there are other possibilities that can work as well. >>> The main condition is that the central solution supports the CC >> metamodel >> and contains all the CC-related metadata in a way that can >>> be processed. >>> >>> The syntax-neutrality has nothing to do with the format that is used >>> to >> store the data. Syntax-neutrality is inherent in the data >>> itself that will be stored, on condition that this data reflects the >>> CC >> metamodel and metadata. >>> >>> Frank >>> >>> Michael Adcock wrote: >>> >>>> A completely syntax-independent STANDARD at the level of business >>>> process models, information exchanges and information content >> is what we >>>> require. This STANDARD must not be compromised by any >> 'bending towards' >>>> any particular solution, it must be kept pure. Every solution >> will need >>>> a 'compromise layer' between it and the standard, in which any >>>> compromises such as extra information etc can be recorded. Such >>>> compromises MUST NOT find their way back into the neutral standard. >>>> Ultimately those responsible for assessment, harmonisation >> and approval, >>>> and those responsible for registry/repository maintenance, must >>>> adhere >>>> to this principle. >>>> More than anything I fear 'compromise under pressure': I have seen >>>> the >>>> results all too often! >>>> >>>> Mike Adcock >>>> Standards & Security Unit >>>> APACS - Association for Payment Clearing Services >>>> Mercury House, Triton Court >>>> 14 Finsbury Square >>>> London EC2A 1LQ >>>> Tel: +44 (0) 20 7711 6318 >>>> Fax: +44 (0) 20 7711 6299 >>>> e-mail: michael.adcock@apacs.org.uk >>>> >>>>>>> Philip Goatly <philip.goatly@bolero.net> 12/02/02 09:32:08 >>> >>>> Folks, >>>> >>>> Since ebXML has endorsed the UMM modeling initiative, then I guess >>>> that >>>> if we are to have a complete modeling >>>> language for e-commerce it must include the 'static data' as well. >>>> This >>>> of course includes what are called currently >>>> core components. So I guess you are stuck with UML, or UMM must >>>> become >>>> XML based :-) >>>> 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> >>>>> >>>> >>>> ---------------------------------------------------------------- >>>> To subscribe or unsubscribe from this elist use the subscription >>>> manager: <http://lists.ebtwg.org/ob/adm.pl> >>>> >>>> ********************************************************************** >>>> The opinions expressed are those of the individual and not >> the company. >>>> Internet communications are not secure and therefore APACS does not >>>> accept legal responsibility for the contents of this message. >>>> If the reader of this message is not the intended recipient, or the >>>> employee responsible for delivering this communication to the >>>> intended >>>> recipient, you are hereby notified that any disclosure, >> distribution or >>>> copying of this communication is strictly prohibited. If you have >>>> received this communication in error, please notify us immediately >>>> by >>>> telephone to arrange for its return. Thank you. >>>> ********************************************************************** >>>> >>>> ---------------------------------------------------------------- >>>> 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> >> > > > ---------------------------------------------------------------- > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC