We have seen that WCS is actually a layered system. Now it is time to go into the details of each layer to see which features they provide.
The core of WCS is the Content Server layer. Although until recently the whole product has been called "Fatwire Content Server", actually Content Server is just the first layer. You actually call Content Server when you invoke the URL "/cs/ContentServer" (or "/servlet/ContentServer" or whatever your context path is)
ContentServer is basically an interpreter of an XML-based programming language developed before the year 2000 (presumably around 1995). It looks like the original developer wanted to implement a sort of custom ColdFusion-like but extensible programming language. I am familiar with the idea since at the time I built something very similar.
At the time of the initial development of WCS, the new XML standard was very young, and its purpose was a bit unclear. The obvious idea was to use XML as a programming language, and using the custom tags programming constructs. I think so because I thought exactly the same thing.
Today I would say that it was not such a good idea mostly because XML is not really suitable to be a good programming language. I notice however that other CMS (for example, OpenCMS) works in the same way, and have a custom language based on XML.
The Content Server XML is not generic XML, but a sort of custom programming language that I will call it, not having a better name, CSXML. Later WCS added to the CSXML with something more standard, and more general: JSP, allowing programmers to use the more familiar Java programming language instead of a proprietary and somewhat limited programming language.
One funny thing in Content Server is that it still uses an XML parser, written in Java but developed by Microsoft! If you look to the jars in the WCS installation, you can still find the MSXML.jar. There was a time when Microsoft was Java friendly (they licensed Java and developed a version of Java for Windows for a while). Then they moved on... and C# is another story.
When XML came out, Microsoft developed one of the first XML parsers, an open source one, and it is the parser that still today ContentServer uses to parse his CSXML. Please note that the MSXML parser is not even standard compliant since it was developed before there was actually a standard for XML, and it has some oddities. It is not validating, and it has tag names case insensitive , but attributes are case sensitive...
CSXML is extensible, in the sense that you can develop custom tag libraries and invoke a tag. It is widely used in WCS since large part of the Xcelerate and Gator layers are developed in CSXML. You also need to use CSXML when you want to customize the interface.
Actually not everything in Content Server is implemented in CSXML. CSXML is a sort of scripting language to implement the user interface but all the underlying logic (especially the database access logic) is actually implemented in Java, packaged in jars and called through tag libraries. There are many tag libraries and only a fraction of them is actually documented for site development purposes.
CSXML is not the only way to develop for Content Server. There is also another, more standard, programming language available: I mean plain simple (and standard) JSP. So basically you have the choice of using CSXML to code your site and customizations, or use standard JSP (that of course allows you also to code the logic in pure and simple Java).
However, ContentServer is not just a plain JSP interpreter. It provides a lot of other services, that in CSXML are accessible through custom tags. The same is true also for JSP. The smart idea is that every tag defined for XML is available as a custom tag library for the JSP, with the same name and the same attributes.
So for example you can load an asset in CSXML using
<ASSET.LOAD TYPE="..." OBJECTID="..."/>,
bug you can do the same in a JSP using
<asset:load type="..." objectid="..."/>
Of course it is not just that in JSP you can use asset:load while in CSXML you use ASSET.LOAD. There are many other differences, in JSP you can use scriptlets, expressions like <%= ... %> and <% ... %>, while in CSXML you cannot, and you have to use a string replacement mechanism provided by CSXML for variables. For simpler things you can use CSXML but it becames easily too limiting. I am not going to go into the details however, since I consider CSXML leagacy and I will focus mostly on JSP.
