Preserved Topic: Content Management Ideas

I am looking into content management systems and I have not been very impressed by the way that the content is stored. I think that this is due to the fundamental nature of the HTML, but I am not completely sure. When I look at most systems the content is either stored in an HTML format, uses some psuedo markup language or is flat text, with no markup.

None of these solutions make me really happy. It makes the separation of content from style which is the current paradim very hard to keep true to.

So this leads me to the portion where I solicite input from any and all members that are willing to write out a few lines in a post.

How would you sugest a CMS handle content? This is not based on whether you use a database of XML, but how do you store the actual data. Formatting is a large part of how content works. It is important to store elements such as a list using the list formatting, it is important to store tabular data in a table. But should you use HTML to markup the data in your storage medium?

Is there a better way to handle all of this? Have you seen a system that would allow the effective creation of a site like the csszengarden, or even wired? Do you have ideas on how you would work such a system?

I intend on writing my own php cms in the near future. Just on a basic level i would have expected the data in the database to be unformated, maybe with the exclusion of <br /> (maybe even <p> tags depending how the database handles end of lines. It maybe possible when you are extracting data to also detect end of paragraphs in the database - not sure.

Obviously it depends alot on the site, but i think ideally you want raw unformatted text, so that you can then format the text the way you want using CSS markup.

That way if you even want to change your page layout, its irrelevant of how data is stored.

The same question struck me when I was writing the CMS for my homepage. You need to keep the structure of the text you can't store is as plain text. The best solution I managed to come up with was to format the stored data using XML. Storing it as XML also allows easy transformation between different output formats which is always nice.

It is probably not the 'perfect' solution to the storage problem, since you end up storing a bit of the formatting alongside the content. But as long as you only use tags that are used to format the text correctly (<p>, <li>, <hn>...) it shouldn't be a problem converting between different media, since similair formatting has to be done before displaying it in all medias. But you should avoid using media (web, pdf..) specific markup in the stored content, because that is information that might be difficult to transfer to another media.

Looking forward to seeing what other people think about this

_________________________
"There are 10 kinds of people; those who know binary, those who don't and those who start counting at zero"
- the Golden Ratio - Vim Tutorial -

I agree that it needs to be stored as unformatted as possible. When I did the CMS for a large site, I stored all of the text in the db without hardly any formatting. The only thing in there was the <br /> from nl2br, and some occassional <span> tags. All of the other formatting came in the templates, including converting URLs to links, inserting sidebar text, etc.

There were some exceptions, but this was the easiest way to do it. Especially when you get the itch to redesign things and want to use the same content in another format.

That is what I was afraid of. You can't avoid code in the storage medium. I was thinking a lot about this and I really can not see any way around this. At the same time if you are looking to store rich content you can't really dis-allow many tags. It just depends on how much functionality you want to give to your end user.

I still think your better off storing as little as possible formatting for the text, how does this really limit the functionality to the end user? I dont think it does at all.

All you really need is the data, you can display it anyway you want on your page. Even if you want to have different formatting options, theres nothing to stop you having the formatting sets stored also in the database to build your css or whatever you are using.

To me, storing the data with most of the formatting already done kind of defeats the purpose of using a database etc..

But remember i havnt actually built my CMS yet, so i may have a different opinion later, right now tho thats how i plan it =)

I agree with the 'fact' that less formatting is better. But the problem with storing (almost) no formatting with the content is that it will be difficult to display the content as it is supposed to when you retrieve it afterwards. How are you supposed to figure out if that is some sub heading is a <h3> or an <h4>? How are you going to store tabular data? What about links; how are you going to store both the url, the link name and the title attribute? etc

If you can dismiss some of those options (for example tabular data) it becomes easier and you can use less/easier formatting in the stored data. But I think you'll still need some kind of markup or formatting to displayed the stored information correctly...

_________________________
"There are 10 kinds of people; those who know binary, those who don't and those who start counting at zero"
- the Golden Ratio - Vim Tutorial -

For the CMS I worked on for some big intranets/extranets, the strutucture of the site was stored in a database, and the contents were stored in XML files. There was some sorts of DTD to describe the various types of contents, that is to give the name of the elements, their internal types, their possible number of occurence and their possible children elements. The internal types were simples : plain_text, date, numeral, URL, file, rich_text, ... Only the contents of type rich_text were enclosed in a <[CDATA[ ... ]]> block to allow little formatting, otherwise ALL the formating was done by some XSL files.

Hope that helps,

I guess the issue comes down to how you display your data, i see the issues ven pointed out. How much data do yo store in one block in the database. Is there any reason why you cant store a block of data which goes under a heading, and store the heading to that block of data also? The general format i guess is one main heading for the content, then a sub heading for the block of content. I probably wouldnt store the main heading at all, however if its wanted to be changed in the CMS you still could.

Tables are more of a big issue i guess depending on how you do it, and what you are doing with them. If its a table of data then in most cases i would be pulling the table data from a database anyhow, then formatting it as required. If you are using the table to display images, still dont see a problem there..

As for the links, obviously if they are embedded in the text like so then that is a tricky part - you probably dont have much in the way of options there, there has to be as you said something that tells that part of the code that it is a link and what its attributes are. The same goes for any bold or italic segments within the paragraph body. You could put custom things that your php extracts at a later stage, but if your doing that you might as well format it with <b></b> etc straight away.

So basically really the only issues i see are formatting within a body, for headings etc they should never be actually inside a paragraph so i dont see an issue there.

On another note - to me the point of a content management system is so that someone with little knowledge of html/scripting etc can manage a site you build for them, adding and removing content as they require. If you were going to completely format the code that you put in the database, are they supposed to know all the tags, what they do etc? The interface will need to handle bold, links, underline, italics within the body which is quite easy - but if they have to deal with the entire markup then to me thats not a goot content management system, you might as well tell them to use notepad and change the file themselves.

Anyhow thats my opinion on it, i'm trying to see the best way to do this, obviously there isnt necesarrily ONE way to do it, or a BEST way to do it either - most of the time it comes down to what you actually want to do with it. It would be nice to have one standard CMS that handled everything tho wouldnt it ...

That could be an option too, the user can select formatted or unformatted for each entry and then you deal with it when you parse your php or whatever.....

I forgot to precise that our sorts of DTD were parsed to generate the forms by which the end users entered their contents. That way the XML structure and internal data types are completely transparent to them.

A bit late to the fray, but here goes...

IMHO, it is impossible to completely separate content from style/structure. The reason it is impossible is you need "hooks" in the text if you want to do any sort of styling to it. For example, if I want to style acronyms a certain way, I need to mark them as such in the content. Veneficuz mentioned headers above, which are another good example.

I'm sure the fact that it is impossible to achieve this ideal has something to do with it, of course, but I never personally felt the need to adhere slavishly to the new "paradigm." In fact, I don't really think it's a good idea to adhere slavishly to any paradigm. These concepts are supposed to make our lives easier--they are not supposed to be puzzles that we need to solve.

Basically, I would say that as much separation as possible is good, but you're going to find (or have already found) that complete separation is not only impossible, but not desirable. Bottom line: go with what works for you, go with what makes your life easier, both in terms of the present and down the road.

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | Keeper of the Juicy Bits

We partly touched on this over at the GN when discussing the problem of templating:

http://www.gurusnetwork.com/discussion/thread/2628/

___________________
Emps

The Emperor dot org | Justice for Pat Richard | FAQs: Emperor | Site Reviews | Reception Room

Ah, you are correct about not having to adhere slavishly, but. The ideal is very good and I can seem many reasons why this would be completely desireable.

The reason I am looking for such a method of data storage is because I can see a time when the structure - being XHTML - will become obsolete. I am not assuming this could be 5 or 10 years away or more, but it will become obsolete, but content shouldn't become obsolete nearly as soon.

The current CMS systems are very very old. They still rely on tables for their markup, and those that do use CSS for presentation do so in a very horrid manner. I would never code my site in the manner that a CMS system would.

I am trying to come up with a method that would satisfy my XHTML/CSS coding standards as well as keep track of the data in a method that would be intuitive for the end user.

There doesn't appear to be a "good" solution to this. I am all for one, I just can't see it.

WarMage: My solution is to use a range of UBB-style tags and processing (like turning like automatically creating paragraphs, etc.) that way it is easy enough to adapt the actual code to output in the desired format. For example after this discussion:

http://www.gurusnetwork.com/discussion/thread/1885/

I have been looking into adapting those scripts so they produce DocBook XML (as well as XHTML) which can then be processed through XSL into FO (as used by things like FOP) and from there into other formats.

___________________
Emps

The Emperor dot org | Justice for Pat Richard | FAQs: Emperor | Site Reviews | Reception Room

I was wondering do most people use dynamic pages with CMS like your php file, or alternatively create a new static html file when the CMS user is finished doing what he is doing to the page (or at some other stage).

This way you could always generate static pages, maybe be more search engine friendly?

My $0.02...
As far as I'm concerned something is missing in this discussion.

Namely the answer to this:
In what situations should the content be used?

This tells us if we are working with a WCM or CMS type application (to me there is a world of difference here).
- If the answer is internet/intranet/pda/cellphones or any other variation of browserbased access, then we need a WCM (Web Content Management).
- If the answer is to handle content to be shared in office applications, web-based, CRM systems, ERP systems, print, content ownership, versioning and so on. It's a CMS (Content Management System).

I'm sorry to be picky here but as I said, it's a lot of difference here, and the end usage of the content in large part also controls what requirements/principles should be applied to the storage-format.

If we are looking at capabilities such as a true CMS here we need to create/allow for maximum flexibility in the storage format in order to be able to process the content into all the different enduser formats. And the only choice I can see that can manage this today and which also is somewhat "future-proof" is XML.
Then you have to answer the question on where to store the XML, in a database or as files or...


If we limit ourself to beeing able to display content to a mainly browserbased enviroment things get simpler (or harder perhaps).
Simpler in the way that we can narrow our requirements to the lowest common denominators for the enduser formats to support. Say you will support normal webbrowsers, modern pda's but not wap.
To be honest, you will have to somehow disallow all presentation-tags that can't be displayed ok in a modern pda since that sets the lowest standard.
How do you do this?
- Well, you can disallow entering all tags except a select set that you know works for all end users, then you can store this in a db or files as "rich text" containing formatting.
- Or you can choose the path of a special set of substitute tags such as UBB-style or similar, this you can then parse for output differently based on the choosen template.
- Or you can choose to use XML.
- Or you can custom design an interface for datatemplating where you can create sets of different storage templates for different types of content (something similar to what poi wrote about if I understood him correctly).
- Or you can come up with your very own solution...

This does not tell you what is right or wrong because there is no such thing.
It's all a matter of choosing an appropriate level of separation between data and presentation based on how the system should work and what endusers you should cater for, today and tomorrow.

The more flexibility you need, the more neutral your dataformat for storage must be.

Personally I have chosen to go for storage in a very flexible database combined with an interface that gives the siteowner the possibillity to create admin templates for datastorage in almost every possible way you can imagine. This way he can create templates that store pure data with no formatting what so ever, where a page can be divided in multiple parts that have different tags/datatypes if they please. Or a page can be one complete block of HTML if that's what they need. The site can then use one or a hundred different templates like this totally based on their needs. The data stored with these datatemplates is also connected to an output template that process the datastructure into the chosen output, be it HTML, XML or XHTML for Browsers, PDA's, applications, or spacedelimited textfiles for ERP systems and so on.

That's my choice, to create a system that allows the owner to create the structure he needs and enforces the rules for that structure inside the system.

What's your choice?

/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Ahh if thats the case i was talking about WCM - i just thought they called it CMS too T.T. I dont see quite as much about WCM out there.

I know, I guess I'm just a stickler for detail
No really, systems like PHP-NUKE, postnuke and similar are definately part of the WCM category, more advanced systems like EZPublish, Typo3 and a lot of others can do parts of what a CMS can do as well as the WCM parts, things like Vignette Story server, Documentum, MS CMS and several others are expensive commercial options and more geared to target a wider scope of responsibilities, in this segment you also have a wide range of open source solutions built on Zope, Plone and a lot more.

A really good definition is this (snipped from http://www.cmswiki.com/tiki-index.php?page=IntroToCMS ):

quote:

---

"A content management system (CMS) supports the creation, management, distribution, publishing and retrieval of corporate information. A CMS addresses the complete lifecycle of content as it moves through the organisation"

Note that most products in the market focus on web content management (WCM), that is, the management of HTML content on websites and intranets.

---

A decent introduction can be found here: http://www.cmswiki.com/tiki-index.php?page=ContentManagementSystem
And here http://www.cmsinfo.org/ you can find a lot of links/news and info on appr 80 different mostly open source cms/wcm systems.

I've learned tons from following discussions on http://www.cms-list.org/ as well ( been down but is slowly coming back, archived at http://archivist.incutio.com/viewlist/cms-list ).

H][RO, there are lot's of different opinions on how to create the pages in a cms.
Mine is this:
If you don't expect loads & loads of traffic (tens of thousand/day) you'll do just fine with "regular" php pages that poll data and assemble the pages to each visitor.

What you do to make it searchengine friendly is to rewrite the url so you don't pass visible parameters in the url or rely on POST-data for everything.
Meaning:
"...dmsproject.com/index.php?pId=5" turns into "...dmsproject.com/index/5/" as an example, in this case "/index/" would point me to the template to use and /5/ would be the page-id to retrieve content for.
These rewritten urls are used everywhere instead of the passing of parameters and are rewritten and translated by the server and your scripts.
This way the searchengines see these links as regular links and will have no problem following them in order to index your site.

If you are building for tons of traffic you might need to look at some sort of caching, either a cache that reduces the number of database accesses and/or reduces the server processing needed to assemble a page.

There are tons of different ways to do this as well, one beeing to periodically generate a static HTML-version of the whole site, or selected parts of the site. This increases speed quite alot since a webserver normally can serve several static pages in the time needed to poll the database process the page and serve it as HTML to the user.

Another way to do this is to use what normally is called "remote publishing" where your ca CMS reside in one place and create static html that is ftp'd to the live server.

Hope it cleared up some things
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Yeh it does thanks

I really need to figure that php URL thing out, i still havnt done it - for some reason it seems daunting too me, but im guessing its probably not that hard to do T.T (know of a good tutorial for this? im not sure what its refered to as)

The scale im looking at initially will be pretty basic i guess, just website content management for clients etc, so probably not too hard i hope. I will do it from a database etc and format as i need. Also i will probably have a page so they can change CSS settings without having to know how to code at all. (nothing that new really i beleive phpbb forums do this in a quite simple way with the default install).

Ive taken a look at your site DMS, your project sounds interesting i might look into it a bit more. I still havnt got around to learning XML im guessing it would be useful for something like this. Alternatively it would be php that i would use to get the data then present it how i want.

Are you using php/xml or something? or a bit of both i guess?

(Edited by H][RO on 05-17-2004 14:52)

For the search engine friendly urls just search pun intended
http://www.google.com/search?q=apache+search+engine+friendly+urls+mod_rewrite

As for my stuff, no XML at this point.
I store things in MySQL if it's not uploads, then that goes in the filesystem.
All serverside code is PHP, trying to do it OOP as far as possible.

Should I need to output XML, I'll do it through templating as I pull data from the database, in my case I'll treat XML as another presentation format. I might build something to handle input through XML as well, but that's far ahead. As I want it, the stored data should still be "pure" data if the situation warrants it.

As for the info on my site, most of it is centered around the second beta that is downloadable on the site, what I'm doing now is a complete rewrite from db and up since beta 2 turned out more as proof of concept.
This: http://www.dmsproject.com/index.php?pId=28 is the little snip up yet that covers beta 3, plus the early code documentation.
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

So it does boil down to the fact that there is no really "good" solution to the problem.

I was looking at plone. The code generated by it is better than any I have previously seen, but it is still not amazing code wise. I think I am going to tinker with this for a while. The port for freebsd is broken right now, so I will play with it when that gets fixed.

Yeh well i guess you really have to set what you want it to do and take it from there.

I was looking into XML, im really not sure what the point of it is still - as far as i can tell its really just a data storage medium. Truly it doesnt look much different to putting data in some kind of database. Maybe im missing something i guess ill keep reading, currently tho it seems like they are trying to reinvent the wheel with it T.T

XML is normally (which actually means hardly ever) used between the database and the presentation. You can take your data out of the database and place it into an XML file for transmition. This allows for easy data transmission between different databases.

Say you have a database Containing the fields:

price
amount
id

And person 2 has a database

cost
number
product-id

If you both want to cross list the same products on two websites XML works as the intermediary between the two to transfer the data.

Other uses of XML are for technologies like SVG or WAP or DocBook XUL or many data formats.

XML is often confused for a solid stand alone technology, while in reality it is a building block that other technologies make use of for data storage and retransmition.

Yeh i guess thats what i have a problem with, why bother doing that transition when you could just turn the database data into something you want anyhow.

I mean for me to transmit from my [price] field to their [cost] field, im still going to need some sort of code that knows these are the same thing, so why bother with XML.. Just seems to me that its taking an extra unnecessary step.

I dunno maybe im still missing the point lol T.T



On the other kinda unrelated topic of search engine friendly URL's. Will search engines only complain about your page if it has extra stuff after the php, like .php?id=22 etc.. What if its just myfile.php - will this then technically get indexed exactly the same as a standard html would?

AFAIK, search engines will not complain about the URL itself, but I could be wrong. I rework my URLs on my site*, but not for the search engines--I do it because it is a lot easier to remember neat and simple URLs.

*what I do is a break up url queries and then feed that information to a central template that processes it and spits out the proper content--I think this is a bit different from the way most people go about it.

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | Keeper of the Juicy Bits

URL rewriting is done here and at http://www.gurusnetwork.com/ a great deal. When I wrote my WCM app for another site, it was a REAL learning experience. There was more than one occassion where I went back and switched things around a little to accomodate growth. As your needs grow, you'll see more and more need to strip out any formatting and just store the data in an unformatted format in your db. You can then draw it out and style as needed.

In my application, I queried the data for inclusion in dynamic PHP pages, as well as in RTF formatted data (for email), XML for RSS feeds, etc. All from the same database.

While I wouldn't "welcome" the chance to do it again, doing it from scratch was quite the experience.

Do you think there is any point in doing it these days Pug?

Its always hard with search engines getting the facts hehe, even the big SOE companies have trouble. Im not too fussed really about how the URL looks, my main concern is search engines. I guess if it doesnt make a different then my time could be better spent learning something else.

Also im using windows servers so not sure if it requires any linux stuff to do this or if the server is irrelevant.

Hiro I agree, I've never found the use of transforming results of a db query into XML to then be transformed into HTML. It's almost easier to just create a seperate XML feed if that's needed.

XML is really not a storage medium but markup for data transmission. I've used it a lot in that situation. The cool things about XML is that it can be parsed in a stream as opposed to as a chunk which makes it very usefull for parsing large chunks of data over something like a socket connection that can just stay open.



.:[ Never resist a perfect moment ]:.

Ahy H][RO you stepped on an important issue. XML has a sister technology called XSLT which is an XML based tool that does the transition from one type of data to another, so that you don't need to use a different technology to do the translation.

Oh ok, im just trying to see what they are aming it.

Deep down all XML is, really is a data storage medium. I guess there is some advantage with streaming as what bitdamaged said (im guessing databases you get chunks of data), but other then that - i dunno.

Do you know of any practical examples, where you cant just pull data from a database.

-Most cases you will have your database, you need a database - this really wont change, you could replace it but it would only be with another type of database.

-Then what, you need to get the data you want from the database and display it on the system/format you want. So you have 2 options
1. Extract the data from the database to into xml format, then translate that as required
2. Extract the data straight from the database and translate it as required.

XML is really just setup following the structure of a database anyhow, they even reccomend you to do it like that. Either way you need some method, some code to get the database data into the XML form... and then translate it. Why not just the method that gets the data to also translate it.


I guess thats the problem im having, that and the fact that all these places are saying "XML is the Future" etc... Well the point is i guess im confused even more after learning a bit about XML lol... maybe im still missing the point completely.

The only way i could see XML being of use is if it did replace databases, however it doesnt seem like an "efficient"? medium to do that to me.

So anyhow, i dunno - am i working along the right line of thinking or have i screwed myself up completely? :P

No, you're not screwed up
In some ways I agree with you, however there is one thing that the use of XML-standards give you that Bitdamaged touched on. Data transmission.

If you look at XML first as a way to structure and tag data you can easily see that it's quite easy to restructure information pulled from a database, for example data from the table "price" could be tagged with <cost>50</cost> without problems. This you can then transform into several different presentation formats using CSS or XSLT. If you are looking at this soley within your own site I agree, you can do this using a lot of technologies.

Now if you look at this from the outside, to serve your content as an RSS feed enabling others to online show your news on their site you should use RSS (it's the standard for this) and then you need to transform your data into XML. To re-structure your data here can be very useful to help the feed users understand what you are sending. Your data might come from a database design where one iten is compiled from several tables, if so, it's easy to tag this with one cleartext xml-tag.

The next step is where you actually need to consolidate/share/syncronize data with another site.
Instead of using fixed forms and similar things you can use webservices.
A webservice is actually an API in XML to selected functionality on your site, this functionality might be a PHP-class with methods to poll and process data to and from the database, or a .dll on an MS server.

The standards for this has been up to now XML-RPC which is beeing replaced by SOAP (Simple Object Access Protocol). These are actually wrappers for XML-data that is passed back and forth between the sites. You are in fact communicating between different functionality on different sites by using a common language. Linux platforms talks to MS platforms seamlessly and only the functionality you want exposed is exposed through method-names in the wrapper.

Example (in XML-RPC):
Site A sends a POST to Site B to recieve todays news, the post looks like this:

POST /xmlrpcInterface HTTP/1.0 

 User-Agent: SiteB XML-RPC Client 1.0 

 Host: xmlrpc.SiteB.com 

 Content-type: text/xml 

 Content-length: 195 

 <?xml version="1.0"?> 

 <methodCall>    

 <methodName>news.getTodaysNews</methodName> 

   <params> 

     <param><value><string>2004-05-18</string></value></param> 

   </params> 

 </methodCall>

Site B answers with something like this;

HTTP/1.1 200 OK 

 Connection: close 

 Content-Length: 148 

 content-Type: text/xml 

 Date: Tues, May 18 2004 09:59:04 GMT 

 Server: SiteB XML-RPC Server 1.0 

 <?xml version="1.0"?> 

 <methodResponse> 

   <params> 

     <param>

	 <value><string>New article 1</string></value> 

                 <value><int>1</int></value> 

     </param>

     <param>

	 <value><string>New article 2</string></value> 

                 <value><int>2</int></value>  

     </param>

    <param>

	 <value><string>New article 3</string></value> 

                 <value><int>3</int></value>  

     </param>

     <param>

	 <value><string>New article 4</string></value> 

                 <value><int>4</int></value> 

     </param>

   </params> 

 </methodResponse>

This Site A parses this using XSLT and generates a list of news headings with links, each link can now be a new call to the webservice on Site B that looks something like this:

POST /xmlrpcInterface HTTP/1.0 

 User-Agent: SiteB XML-RPC Client 1.0 

 Host: xmlrpc.SiteB.com 

 Content-type: text/xml 

 Content-length: 195 

 <?xml version="1.0"?> 

 <methodCall>    

 <methodName>news.getFullArticleById</methodName> 

   <params> 

     <param><value><int>2</int></value></param> 

   </params> 

 </methodCall>

And now we answer with:
Site B answers with something like this;

HTTP/1.1 200 OK 

 Connection: close 

 Content-Length: 148 

 content-Type: text/xml 

 Date: Tues, May 18 2004 09:59:04 GMT 

 Server: SiteB XML-RPC Server 1.0 

 <?xml version="1.0"?> 

 <methodResponse> 

   <params> 

     <param>

	 <value><string>New article 2</string></value> 

                 <value><string>Ton's of text on article 2 here.</string></value>  

     </param>

   </params> 

 </methodResponse>

And there you have it.
By creating a webservice with a common standard using an API with some selected methods exposed you can now share content in full with other sites without giving access to your database or source code. Plus it's totally platform independent. The "client-site" just has to know the url and what methods he can use.

XML and it's related standards are useful today. However you do have to know what you want to accomplish and what role you want XML to take. If you plan to do a lot of things like this for an intranet that will interact with a lot of different backend systems this will probably play a big role in your solution.

(total disclaimer: all code is for illustrative purposes only and are not tested in any way)
Cheers/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

(Edited by DmS on 05-18-2004 10:22)

Ok, thanks DMS, that does clear things up alot. I can see then why you would use xml, i guess being so simple and with clear text tags that anyone that wants the data doesnt have to know anything detailed and can just do what they want with it.

If thats the case im not sure i have a use for XML just yet hehe. In the above example would the data generally be extracted to an xml file, or are xml files usually just created as temporary files everytime someone makes the call to your site?

Anyhow thats not really important - i guess i was thinking of how to use XML in a CMS/WCM (back on to the actual topic), but if it is just a WCM situation then im not sure there is any point. In a CMS though im sure it could be much more use, if data transmission is required.

I guess (yeh i do this alot!) that you could perhaps use it even in a WCM situation and translate it into your HTML pages, then for future if you ever want to put that information on a PDA etc it would probably be easier, just write a module converting the XML to what you need, and leave the database -> XML stage alone.

Something to think about i guess, i want to start my CMS, er WCM later this month so it should be a nice challenge!

quote:

---

I guess (yeh i do this alot!) that you could perhaps use it even in a WCM situation and translate it into your HTML pages, then for future if you ever want to put that information on a PDA etc it would probably be easier, just write a module converting the XML to what you need, and leave the database -> XML stage alone.

---

Spot on!

/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-