RE: ebXML Representation of Metadata

[Cory Casanave <cory-c@dataaccess.com>]

	<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.