Topic awaiting preservation: XML as the spine of a php website

Hello all.
This is a tricky decision to make : I want XML to be the backend of my website.

This XML is meant for three purposes at the time of writing :
1) Backend for a newsfeed
2) Backend for the site content in a web 2.0 "stylee"
3) Backend for the data of a rich media version

I am using php 5, and I have the following questions at hands :
-----------------------------------------------------------------------
(1) should I form the whole as one single xml document?
a. Anybody has articles about the inner workings of xml in php5? It wouldn't be a huge file anyway, so it could be really handy - say the xml api "caches"
or indexes the document at first use, and then I grab bits and pieces through Ajax techniques as required, or xsl the whole to a newsfeed as required.

(2) Should I opt for one document per corresponding web page?
a. Doesn't sound that flexible, and sounds harder to maintain.

(3) How do I go about the dtd of such a document : I feel xhtml should be the "base" or at least one of the namespaces.
a. What else?
b. Should I write my own dtd to complement xhtml, and include each individual web page as a "subset" of it?
c. Should I write my own dtd and use only that, and then map the document to xhtml or rss or (you name it) as required?
d. Is there some pre-existing dtd that could fit the purpose.

And last but not least... Am I leaving out obvious things?

quote:

---

And last but not least... Am I leaving out obvious things?

---

yeah. common sense

XML is a data exchange standard. Not something to replace your database (and a file system is a database as well).
So, delivering in XML is ok - storing in it at large scale is usually a wtf.

(1) Your website's down while you upload your 'not so huge' document. At least here, 'broadband lines' are an order of magnitude slower
going up than going down (yaeh... exageration. but even half a 512kbits of upstream (a lot here), so even a 'small' xml document with 512kb will
take you about 10 seconds to upload.

(2) Would be the way to go as long as you don't need to give other specified access - but in that case, you're down to a server side program anyhow (at least if non technical folks are supposed to use it)

(3) mix and match xhtml and your favourite server side transformation engine (apache org has a decent one, I believe) - you'll need some server side processing anyhow, if it's just for 'includes'.

In the end, you're pretty much back where you started (webserver 'serving' files out of directories - for a given definition of 'serving')

Personally, I've made the experience that fixing up something like word press gives you almost instant gratification if you're wanting to fill your site with content.

But of course, sometimes the way is the actual goal

Nah, I know xml/xsl transforms quite well, they were in use all along on beyondwonderland.com already. For some two years.
You nailed something, but didn't embrace my vision as a whole : xml for data exchange standard.

Quite a requirement if I want to graft different interfaces with minimum hassle to a common backend, don't you think?

The volume of my site is "portfolio, CV, and more portfolio stuff" so it is not to be compared to the Asylum, in terms of size -
and most effective webdesign companies in my country use xml as the backend for the purpose of easy maintenance :
you can map your website easilly to a Word document for example.

See my point now?