[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ebXML Representation of Metadata
<snip> Add to this that XMI creates DTD's that look like they have been written by a machine. I.e. no self-respecting human would want these for a production environment. <CBC> XMI Does write DTD's that look like they have been written by a machine, I strongly disagree with the implied corollary; I.e. no self-respecting human would want these for a production environment. Almost every industry as progressed from the age of artisans to industrialization, and that is what is now happening to software. And, just as the glass blowers of Venice screamed that machines could never produce works as beautiful as an skilled artists the artisans of today have the same arguments against industrial approaches to software. Interestingly, the Venetian glass blowers where correct in their own way, they still make the most wonderful work. But to put glassware on the tables of billions we need the machines. Sure, generated DTD's are not as pretty and the lack character, they are just so consistent and boring - and that is their strength. The consistent way to utilize XML for our purposes is automated and enforced by a well specified generation mechanism. Doing so will enable smarter tools and utilities such that humans will not be dealing with DTDs except at the lowest levels. The esthetic compromises of artifacts such as DTDs being produced with automation is more than made up for by the ability to tool the environment and facilitate industrial software production. Thus it is precisely the "production environment" that demands the consistency and productivity afforded by this approach. I love the art, but this is not the place for it. The other advantage of generation is flexibility over other technologies and over time. XML is today's technology, but what will it look like in 5 years, in 20? Will it be the only thing? Don't we want the domain work that will be going into EbXml to survive the next revisions and even be useful for the next technology on the block? We already know that the DTDs days are numbered. Using automation allows us to keep up with technology changes by modifying our generation parameters without modifying our base models. We can support later versions of XML as well as other technologies as appropriate. Binding the domain work into the technology of the day would be a very short-sighted move. In summary, I think it is imperative that we use automation wherever practical and make a strong separation between the content and the technology. This is the only way we will be part of facilitating the industrial revolution of software. Regards, Cory Casanave Data Access Technologies > -----Original Message----- > From: David RR Webber [SMTP:Gnosis_@compuserve.com] > Sent: Tuesday, May 23, 2000 9:43 PM > To: Duane Nickull > Cc: ebXML-Architecture List; ebxml-core@lists.oasis-open.org; Miller, > Robert (GXS); Cory Casanave; Iyengar, Sridhar > Subject: RE: ebXML Representtion of Metadata > > Message text written by "Duane Nickull" > > > Although I am not an XMI expert, the one persistant shortcoming that I > keep > hearing with XMI is that it cannot provide a "consistent" way to > interchange > metadata. Does anyone have an answer for this comment? > > Duane Nickull > <<<<<<<<<<<<<<<<<< > > Add to this that XMI creates DTD's that look like they have been > written by a machine. I.e. no self-respecting human would want these > for a production environment. > > Now this is a critism - based on the fact that humans write DTD's that > contain a whole level of intelligence and criteria that are NOT part of > a UML model today - such as Oracle SQL optimization criteria, just > as an example. > > OK - this was my point earlier - as machine intelligence increases and > peoples understanding of what a good production quality DTD does > and does not contain, then you can get XMI to mimic this behavoiur. > > We are not there yet! Am I about to 'spray paint the car' so the robot > can copy me 100 times faster right now? I'm probably not ready to > do that either! <g>. > > This is why I see that XMI, UML and related tools will improve, but > not for another one year minimum, as we're all still learning. > > DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC