Lists Home |
Date Index |
Again, if best practices are what is wanted, Roger Costello's
techniques are effective. He is very good at posing 'one
question at a time' and deriving from that. Larry isn't
asking for best practices. He wants formal proofs.
Formal proofs are fine. Tell me what is to be proved. The
problems of formal proofs also have to be understood (the
closed world of axioms elaborated by Hofstadter, self-referential
systems, and so on) but that discussion is something of a
What are the axioms? What is to be proven?
If it is simply justification that an XML-only approach won't
scale up to extremely large live datasets, does anyone
really disagree with XML or with the particular approach
to the database. XML is a syntax. XML applications are
instances of data using that syntax. XML systems are
implementations of XML applications. Do the provable
properties vary by application? Likely.
BTW: over the lifecycle of a dataset, markup has proven by
experience to be remarkably robust if the test is getting
it off a dieing system and onto a new one. Without the
documentation, dumps of relational tables are not very good
for that unless they are dumped in markup.
From: Thomas B. Passin [mailto:firstname.lastname@example.org]
> 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
* 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
* 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
* 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?
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