[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML and the Relational Model (was Re: A standar


relational model pros and cons
[pop3]
> So. I say again. Show me. Prove it. Publish proofs, academically, that
> -  an XML only solution (Heirarchical Model or HM) is better than an dbms
> (RM) solution for the liftetime of the application
> -  a primarily XML (HM) approach is superior over the lifetime of the
> application to a dbms approach (RM).
> -  business cases that show the best practice is primarily, or solely, and
> XML practice.
>
> Open call. Any cases, any process, anything at all. Please. Pretty Please.
> Note that I did not even limit this to DATA only applications....
>

This is ridiculous and it is time for it to morph into something useful.  If
there is no adequate body of theory for xml yet that can provide such
"proofs", then comparison involving "proofs" cannot be made and NO
CONCLUSIONS can be drawn one way or the other.  Talk about strawmen!

There are plenty of things in this general area that would be worth
pursuing, especially if the pursuit could conceivably get anywhere -

* How best can XML techniques be used with very large data stores?  Of
course, this depends ever so much on the nature of the data store and what
it is to be used for.   So an examination of the differentiators would be
useful too.

* When is it better to store data in an XML format than in a relational
format - no fuzzy generalities, but a real discussion, please!

* Normalization - when if ever is it important for information exchanged via
an XML document?  What varieties of normalization should be used when and
why?

* Normalization - in what ways do various normalization techniques help or
hinder xslt or xpath queries?

* Normalization - should "document-centric" XML documents ever be
normalized?  If so, how and why?

* Could a relational database that can store markup be useful for multiple
markup overlays a la Patrick Durusau's work or some of the other experiments
that have been going on?  Pros and cons?

* Are there things in the XML world that are equivalent to relational
database views, and if so what are they and do they have any advantages?
Will xquery change this picture?  Would view equivalents make updates easier
or harder?

* What design patterns have been discovered wherein querying data in an xml
format - as opposed to a relational database - is clearly the preferred
solution?  Please cast them into the classic design pattern form - i.e.,
Name, Problem, Conflicting Forces, Solution, Rationale.

Come on, folks, we could have just as many words flying around, but get a
lot more value out of them!

> What I hear people saying is that XML has no limits, which I find to be a
> preposterous statement. :)

What you have heard consistently on __this__ list is just the opposite.  So
how about contributing to some productive discussion instead of this junk?

Cheers,

Tom P



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.