cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon2 Design
Date Wed, 31 May 2000 12:01:47 GMT
brian moseley wrote:
> On Wed, 31 May 2000, Stefano Mazzocchi wrote:
> > I don't like this. You are placing logic into the URI,
> > thus overlapping the administrator and logic contexts
> > and creating unnecessary (and time-expensive) contracts.
> can you talk a bit more about this? i don't really
> understand your vocabulary (adminstrator and logic contexts,
> contracts).


There is a new field of software engineering that emerged concurrently
with Cocoon (and indipendently, I found out later) that is called
"separation of concerns" (I called it "separation of contexts", but
concern is more general).

This is more or less the abstraction of the MVC pattern into something
general: each "action" embeds one or more "concerns". Both "action" and
"concern" must be taken in their most general common-sense definition.

MVC, for example, uses separation of concern to separate the complete
action into three actors each with a different concern. In order to do
this, each "concern area" (the actors) must be connected to be able to
communicate. This connection is called "contract".

Another example is the XML model compared to HTML. HTML embeds several
concerns: "layout, metadata, hyperlinking, structure, semantics". The
XML model separates the concerns by introducing specifications as


 page.xml + page2html.xsl = page.html

can be viewed as

 page -(xml)-> parser -(xslt)-> processor -(http)-> client -(html)->

Each protocol, specification, interface, API can be viewed as a contract
between actors that are demanded for different things: have different
concerns. ISO/OSI protocol stack is another well known example of
separation of concerns.

It can be shown (even intuitively) that, if the contracts remain solid,
the work can be parallelized between the two concern areas. For example,
Cocoon can delegate XML and XSLT to Xerces and Xalan _only_ if the
contracts between them (respectively XML and XSLT) stay the same.

Same thing with protocols, languages, API, hardware interfaces, document
schemas, web site URIs, street addresses, phone numbers, etc... each of
them are contracts.

Now, the web was orginally based on three technological contracts:
URL/URI/URN, HTTP, HTML, but soon realized that the _existing_ global
URI space was itself a contract.

The plague of broken links indicates very few people understood the
value of URI as contracts.

For example, the use of file extentions on the web is considered
"normal". This was (somewhat) mislead by early web servers that mapped
the file system space to the URI space directly.

Today, we know that extentions are dangerous because they encode in the
URI information about the resource. So, the URI has two concerns: locate
the resource and indicate its format. Such URIs are not "optimal". For

is a valid URI (technologically speaking), but hardcodes the extention

does not. The second allows, for example, a crawler to request metadata
information about that URI, which can be generated in RDF after parsing
the picture in the JPEG2000 format (which includes metadata about the
picture). But in case the picture is normal JPEG, such metadata could be
expressed in another file and liked thru the serving environment.

Or suppose a wap client comes in and we allow a smaller version of the
picture to be presented... and so on.

Since the HTTP embed precise information about "what" the URI contains
(via MIME-type), the extention is not only useless, but harmful!

Cocoon was designed from scratch to outline the separation of concerns
and enforce it technologically. This is why we have components such as
generators, filters and serializers. Or why we have a sitemap and
matchers and general components.

OOP languages did a huge step in this direction to allow actors to be
"objectized", thus separating concerns and creating API as contracts.
Java went further by allowing the creation of interfaces as contracts
that both side should implement (allowing the separation of the API from
its actual implementation). XML gives specs that can be used as
contracts between server side operations.

Cocoon simply tries to mix all this into a coherent view. This is why
it's called "framework" rather than "server" or "application" or, even
worse, "application server".

> i've always built web applications around the idea that the
> request uri specifies the operation to perform and some
> configuration that is internal to the application decides
> what screen to display.

Let's be careful here to analyze the paradigm you are using:

 "the URI specifies the operation to perform"

this contains two concerns:

- what resource you want
- what operation you need to perform on the server side to generate that

(the third concern, "what screen to display", is already separated and
the configuration is your contract)

Now, the real question is: is this wrong?

Not necessarely.

Concerns should _not_ forced to be separated, but only when they belong
to different to different concern groups.

For example, suppose you have a URI of the form


(I know it's ugly, just an example) which indicates what technology you
are using. Then if you change the technology, you have to change your
URI. This is not different from having an extention on the URI itself.


But if you do


alone, you are both indicating you want the "resource that allows me to
add an employee". No matter what technology you use, you are still in
shape and you URI doesn't require to change.

So, to summarize: contracts should not change and all development and
design must be done to enforce this.

This doesn't indicate that you should not encode more than one concern
into your URIs, just that they should not change frequently.

What I usually ask is: would you put the "designed for eternity" logo on
your web site? :-)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message