Cart
[Home] [By Thread] [By Date] [Recent Entries]
Michael Champion wrote: >On Sun, 30 Jan 2005 12:54:22 -0500, Chiusano Joseph ><chiusano_joseph@b...> wrote: > > >>>-----Original Message----- >>>From: Michael Kay [mailto:mike@s...] >>>Sent: Sunday, January 30, 2005 12:26 PM >>>To: 'Christian Nentwich' >>>Cc: 'Roger L. Costello'; 'XML Developers List' >>>Subject: RE: 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?), > > and in loose database terms there are three tables involved: lots, pickers, and pickers in lots. so we would identify the actors (lots and pickers) explicitly and the create a third table to relate the two. our xml message structures reflect this. and then i don't need deep nesting and id/idref should take care of the details, and it's explicit. :) rick >----------------------------------------------------------------- >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an >initiative of OASIS <http://www.oasis-open.org> > >The list archives are at http://lists.xml.org/archives/xml-dev/ > >To subscribe or unsubscribe from this list use the subscription >manager: <http://www.oasis-open.org/mlmanage/index.php> > > >!DSPAM:41fd36f1132641133611020! > > > begin:vcard fn:Rick Marshall n:Marshall;Rick email;internet:rjm@z... tel;cell:+61 411 287 530 x-mozilla-html:TRUE version:2.1 end:vcard
|
