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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] 3 XML Design Principles - a rebuttal

[ Lists Home | Date Index | Thread Index ]

On Sun, 30 Jan 2005 12:54:22 -0500, Chiusano Joseph
<chiusano_joseph@bah.com> wrote:
> > -----Original Message-----
> > From: Michael Kay [mailto:mike@saxonica.com]
> > Sent: Sunday, January 30, 2005 12:26 PM
> > To: 'Christian Nentwich'
> > Cc: 'Roger L. Costello'; 'XML Developers List'
> > Subject: RE: [xml-dev] 3 XML Design Principles - a rebuttal
> >
> > > The only time they need their data
> > > normalised is at the end of a message flow, when it goes into a
> > > database, but certainly not in XML transit.
> >
> >  Database design and message design have
> > quite different requirements and the optimum design for one
> > is not generally optimum for the other.
> 
> +1
> 
> I was trying to make a related point in my earlier post today:

Let me jump on the bandwagon here.  I think it's dangerous / premature
to talk about XML-specific design principles, especially independent
from the application domain.  It would be interesting to pursue Kurt
Cagle's suggestion that what Roger is talking about is a variant of
Codd's 12 principles for RDBMS
http://en.wikipedia.org/wiki/Codd%27s_12_rules.  Obviously some are
not at all applicable to XML, but it would be interesting to explore
which are.  (Note that the conventional wisdom holds that no
commercially successful RDBMS products adhere to all 12 rules!).

  Maybe there are *document* design principles that are quite
different from database design principles..  That may be what Roger is
trying to do, but I would be wary of tying them too closely to XML
idioms. I also think that Michael Kay and Joe Chiusano may be onto
something that *message* design principles are another thing as well. 
I suppose documents should be optimized for update and display by
humans, and messages should be optimized for efficient creation,
transmission, and processing by computer systems ???

I guess my bottom line is that XML is essentially about representing
documents, data, and messages not about a set of constraints for
designing them. I would recommend that Roger start his effort by
checking out the state of the art in conceptual modeling, information
modeling, database design, etc. and seeing what challenges and
opportunities XML offers (e.g., by being optimized for implicit
representation of hierarchical relationships, maybe?),




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS