You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/10/11 23:22:11 UTC
[RT] Cocoon Emotional Landscapes
I was asked to write a white paper on why Cocoon is better than other
web technologies. This is mostly targetted to managers and executives.
Since it might help you to convince your boss, I'm posting it to this
list.
Any volunteer that translates this into the Cocoon Document DTD is
welcome :)
Also some spell checking and grammar correction.
Yes, you're right, I'm a lazy butt. :)
This is included into the [RT] (random thoughts) series because it
includes many references to things that are yet to come, either in this
project or on the web as a general thing. Moreover, RT's are more fun to
write :)
----------------------------- cut here ------------------------------
Cocoon Emotional Landscapes
or
why you can't afford to miss Cocoon
by
Stefano Mazzocchi
(stefano@apache.org)
Introduction
------------
Everybody talks about XML. XML here, XML there. All application servers
support XML, everybody wants to do B2B using XML, web services using
XML, even databases using XML.
Should you care about it? Given the amount of hype, you can't afford to
go around ignoring the argument, would be like ignoring the world wide
web 10 years ago: a clear mistake. But why is this so for XML? What is
this "magic" that XML seems to have to solve my problems? Isn't this
another hype to change once again the IT infrastructure that you spent
so much time implementing and fixing in the last few years? Isn't
another way to spill money out of your pockets?
If you ever asked yourself one of the above questions, this paper is for
you. You won't find singing-and-dancing marketing crap, you won't find
boring and useless feature lists, you won't find the usual acronym
bombing or those good looking vaporware schemas that connect your
databases to your coffee machines via CORBA or stuff like that.
I'll explain you what the Apache Cocoon project is about and what we are
doing to solve the problems that we encountered in our web engineering
experiences, but from an executive perspective, yes, because we all had
the problems of managing a web site, dealing with our colleages, rushing
to the graphical guru to have the little GIF with the new title, or
calling the web administrator at night because the database is returning
errors without reasons.
I was frustrated of seeing the best and most clever information
technology ever invented (the web) ruined by the lack of engineering
practices, tortured by those "let's-reinvent-the-wheel-once-again"
craftmen that were great at doing their jobs as inviduals but that
couldn't scale and imposed a growth saturation to the whole project.
There had to be a better way of doing things.
personal experience
-------------------
In 1998, I volunteered to create the documentation infrastructure for
the java.apache.org project, which is composed by a bunch of different
codebases, maintained by a bunch of different people, with different
skills, different geographical locations and different degree of will
and time to dedicate to the documentation effort.
I designed the site look (which still remains the same), I designed the
guidelines for HTML creation (which had to run on *all* HTML browsers
that ever existed: tell that to your graphic designers and look at their
faces!), I wrote the scripts to regenerate the site automatically taking
documentation out of each project, and kicked butts around if they
weren't following the guidelines.
But pretty soon I realized no matter how great and well designed the
system was, HTML was a problem: it was *not* designed for those kind of
things. I looked at the main page (http://java.apache.org/) from the
browser and you could clearly identify the areas of the screen: sidebar,
topbar, news, status. But if you opened the HTML, boom: a nightmare or
table tags and nesting and small little tricks to make the HTML appear
the same on every browser.
So I looked around for alternative technologies, but *all* of them were
trying to add more complexity at the GUI level (Microsoft Frontpage,
Macromedia Dreamweaver, Adobe GoLive, etc...) hoping to "hide" the
design problems of HTML under a think layer of WYSIWYG looks.
What you see is what you get.
But what you see is all you've got.
How can you tell your web server to "extract" the information from the
sitebar? How can you have the news feeds out of a complex HTML page?
Damn, it's easy for a human reader: just look at the page and it's very
easy to distinguish between a sidebar, a banner, a news and a stock
quote. Why is it so hard for a machine?
The HTML model
--------------
HTML is a language that tells your browser how to "draw" things on its
window. An image here, a letter there, a color down here. Nothing more.
The browser doesn't have the "higher level" notion of "sidebar": it
lacks the ability to perform "semantic analysis" on the HTML content.
Semantic analysis? Yeah, it's the kind of thing the human brain is
simply great at doing, while computer programs simply suck big time.
So, with HTML, we went a step up and created a highly visual and
appealing web of HTML content, but we went two steps back by removing
all the higher level semantic information from the content itself.
Ok, let's make an example... I think most of you have seen an HTML
page... if not, here is an example:
<html>
<body>
<p>Hi, I'm an HTML page</p>
<p align="center">Written by Stefano</p>
</body>
</html>
which says to the browser:
- I'm a HTML page
- I have a body
- I have a paragraph
- I contain the sentence "Hi, I'm an HTML page."
- I contain the sentence "Written by Stefano"
Suppose you are a chinese guy that doesn't understand our alphabet, try
to answer the following question:
who wrote the page?
You can't perform semantic analysis, you are as blind as a web browser.
The only thing you can do is draw it on the screen since this is what
you were programmed to do. In other words, your semantic capacity is
fixed to the drawing capabilities and a few other things (like linking),
thus limited.
Semantic markup
---------------
Suppose I send you this page:
<page>
<author>sflkjoiuer</author>
<content>
<para>sofikdjflksj</para>
</content>
</page>
now, who wrote the page? easy, you say, "sflkjoiuer" did. Good, but now
I send you
<dlkj>
<ruijfl>sofikdjflksj</ruijfl>
<wijlkjf>
<oamkfkj>sflkjoiuer</oamkfkj>
</wijlkjf>
</dlkj>
tell me, who wrote the page? You could guess by comparing the structure,
but how do you know the two stuctures reflect the same semantic
information?
The above two pages are both XML documents.
Are they going to help you? Are they doing to simplify your work? Are
they going to simplify your problems?
At this point, clearly not so, rather the opposite.
So, I'm sure you are wondering, why did I spend the last two years
writing an XML publishing framework? At the end of this paper, you'll be
able to answer this question alone, so let's keep going.
The XML Language
----------------
XML is most of the times referred to as the "eXtensible Markup Language"
specification. A fairly small yet complex specification that indicates
how to write languages. It's a syntax. Nothing fancy at all. So
<hello></hello>
is correct, while
<hello></hi>
is not, but
<hello><hi/></hello>
is correct. That's more or less it.
XML is the ASCII for the new millenium, it's a step forward from ASCII
or UNICODE (the international extention to ASCII that includes all
characters from all modern languages), it defined a "lingua franca" for
textual languages.
Ok, great, so now instead of having one uniform language with visual
semantics (HTML) we have a babel of languages each with its own
semantics. How this can possibly help me?
XML transformations
-------------------
This was the point where I was more or less two years ago for
java.apache.org: I could use XML and define my own semantics with
<sidebar>, <news>, <status> and all that and I'm sure people would have
found those XML documents much easier to write (since the XML syntax is
very similar to the HTML one and very user friendly)... but I would have
moved from "all browsers" to "no browser".
And having a documentation that nobody can browse is totally useless.
The turning point was the creation of the XSL specification which
included a way to "transform" an XML page into something else. (it's
more complex than this, but I'll skip the technical details).
So now you have:
XML page ---(transformation)--> HTML page
^
|
transformation rules
that allowed me to write my pages in XML, create my "graphics" as
tranformation rules and generate HTML pages on the fly directly from my
web server.
Cocoon 1.0 did exactly this.
The model evolves
-----------------
If XML is a lingua franca, it means that XML software can work on almost
anything without caring about what it is. So, if a cell phone requests
the page, Cocoon just has to change transformation rules and send the
WAP page to the phone. Or, if you want a nice PDF to printout your
monthly report, you change the transformation rules and Cocoon creates
the PDF for you, or the VRML, or the VoiceML, or your own proprietary
B2B markup.
Anything without changing the basic architecture that is simply based on
the simple "angle braket" XML syntax.
Separation of Concerns (SoC)
----------------------------
Cocoon was not the first product to perform server side XML
transformations, nor will be the last one (in a few years, these
solutions will be the rule rather than the exception). What is the
"plus" that the Cocoon project adds?
I believe the most important Cocoon feature is SoC-based design.
SoC is something that you've always been aware of: not everybody is
equal, not everybody performs the same job with the same ability.
It can be observed that separating people with common skills in
different working groups increases productivity and reduces management
costs, but only if the groups do not overlap and have clear "contracts"
that define their operativity and their concerns.
For a web publishing system, the Cocoon project uses what we call the
"pyramid of contacts" which outlines four major concern areas and five
contracts between them. Here is the picture:
management
/ | \
/ | \
style - content - logic
Cocoon is "engineered" to provide you a way to isolate these four
concern areas using just those 5 contracts, removing the contract
between style and logic that has been bugging web site development since
the beginning of the web.
Why? because programmers and graphic people have very different skills
and work habits... so, instead of creating GUIs to hide the things that
can be harmful (like graphic to programmers or logic to designers),
Cocoon allows you to separate the things into different files, allowing
you to "seal" your working groups into separate virtual rooms connected
with the other rooms only by those "pipes" (the contracts), that you
give them from the management area.
Let's have an example:
<page>
<content>
<para>Today is <dynamic:today/></para>
</content>
</page>
is written by the content writers and you give them the "contract" that
states that the tag <dynamic:today/> prints out the time of the day when
included in the page. Content writers don't care (nor should) about what
language has been used for that, nor they can mess up with the
programming logic that generates the content since it's stored in
another part of the system they don't have access to.
So <dynamic:today/> is the "logic - content" contract.
At the same time, the structure of the page is given as a contract to
the graphic designers who have to come up with the transformation rules
that transform this structure in a language that the browser can
understand (HTML, for example).
So, the page structure is the "content - style" contract.
As long as these contract don't change, the three areas can work in a
completely parallel way without saturating the human resources used to
manage them: costs decrease because time to market is reduced and
maintenance costs is decreased because errors do not propagate out of
the concern areas.
For example, you can tell your designers to come up with a "Xmas look"
for your web site, without even telling the other people: just switch
the XMas transformation rules at XMas morning and you're done.... just
imagine how painful it would be to do this on your web site day.
With the Cocoon architecture it's a couple of line changes away.
The Cocoon innovations
----------------------
The technologies defined in the XML model are the base of everything,
but many technologies and solutions were designed and invented by the
Cocoon project:
- the XSP language (eXtensible Server Pages)
- the sitemap concept
- the resource view concept
The XSP language
----------------
There were no technologies that allowed us to create the kind of
"content - logic" separation outlined above, so we specified it. We used
the JSP page compilation model as a starting point, but we designed XSP
to be totally abstracted from programming language used.
This means that you can implement the tags using your favorite language,
without having to force your programmers to use a specific programming
language. At the time of writing, only the Java programming language is
implemented (being Cocoon written in Java), but it's easy to picture
development of other language hooks for XSP once Cocoon receives more
attention.
Anyway, thanks to complete separation of concerns, the changes in the
logic concern area don't impact the other areas and allow more
flexibility in the human resource used in the project since programming
languages will be easily interchanged and XSP is not connected to a
particular implementation (the AxKit project implemented XSP directly in
Perl)
The Sitemap concept
-------------------
XSP allowed us to complete the second contract, but we have three more
to go and all of them start from the site management area.
Site managers are responsible for controlling the resources that are
hosted on the site. A "resource" is not a file stored on a file system
but the view of the data connected to a particular web address.
For example,
http://your.intranet.com/calendar/today
is a "resource" but could be dynamically generated by information stored
on your corporate database.
The sitemap allows site administrators to "compose" the modules that
collaborate to create a particular resource and connect them to the
particular resource address. For example,
<match pattern="/calendar/today">
<generate type="calendar" src="today"/>
<transform src="transformation/calendar2html"/>
<serialize type="html"/>
</match>
or, supposing you want to connect with your Palm to the calendar or with
Acrobat for printing:
<match pattern="/calendar/today">
<generate type="calendar" src="today"/>
<select type="browser">
<when test="palm">
<transform src="transformation/calendar2palm"/>
<serialize type="palm"/>
</when>
<when test="acrobat">
<transform src="transformation/calendar2pdf"/>
<serialize type="pdf"/>
</when>
<otherwise>
<transform src="transformation/calendar2html"/>
<serialize type="html"/>
</otherwise>
</select>
</match>
yes, it's that simple, the above is a real working example. Given the
right logic components and transformation rules, the site administrators
to just that: compose the modules to create web sites and web
applications.
Of course, there are situations where the logic involved in the
componentization is much more complex than this, but the sitemap concept
allows to finish the implementation of the five contracts without
overlapping between the concern areas.
The Resource View concept
-------------------------
The third big innovation of the Cocoon project is the notion of
"resource views". It's kind of an abstract concept so I'd like to start
with an example to explain the problem.
A big XML myth is that a web of XML content would be easier to searching
and index given the uniform syntax.
This is simply dead wrong.
As one of the first examples clearly showed, there is no way for a
search engine to perform semantic analysis on something like
<dlkj>
<ruijfl>sofikdjflksj</ruijfl>
<wijlkjf>
<oamkfkj>sflkjoiuer</oamkfkj>
</wijlkjf>
</dlkj>
the only useful thing would be to ask for all the web resources where
"sofikdjflksj" is included into "ruijfl" tags... but if you think at the
possible huge babel of XML languages that might appear in the next
decades, this is a clear problem.
The RDF (resource description framework) model is an effort that aims to
reduce this problem by creating uniform semantics to "describe" any kind
of information. For example, it could allow the author of this weird
markup to indicate that
<ruijfl>
inherits the semantic meanings of <author>. So, if you search for
"sofikdjflksj" as an <author>, it will be able to search between
<ruijfl> as well.
It will be a happy day when there will be enough RDF information on the
web to allow such semantic-rich searching, it will correctly be a much
better web for search and retrieval of information.
The problem is that all other publishing systems except Cocoon "hide"
this information inside the system, there is no standard way to "ask"
for the original RDF-ized semantic content of the requested resource.
There is no way to ask for a particular "view" of the resource.
In Cocoon you can define "views" for each resource or group of
resources: you can ask for the "content" view, or for the "schema" view
(that returns you the structure of the document and the information to
validate it), the "link" view that returns you the pages that are
connected to this particular resource and so on.
Resource views are a particular type of HTTP variants, but targetted for
the yet-to-be-possible semantic indexing of content.
Cocoon itself uses the view for its batch mode: it performs as a crawler
and saves a snapshot of the site on disk, useful for creating offline
documentation or CD-ROM snapshots of dynamic web sites.
Cocoon present
--------------
The Cocoon project is currently discussing new features such as "content
aggregation" that would simplify the creation of portal-like sites where
content is aggregated from different sources into the same page.
At the time of writing, the design has yet to solidity.
Cocoon future
-------------
In the future, Cocoon will provide local semantic searching capabilities
allowing you to gain immediate advantage of the time invested in
creating highly semantic content for your site.
I believe this is the only way to convince people to invest time and
resources into creating a better content model for their local
information. We still don't have any idea on how this will happen or how
it will work, but I believe the Cocoon project has a major role in the
promotion of the next web generation and semantic searching is a big
part of it.
We'll do whatever it takes to help the semantic web to exist.
A further future goal is to allow Cocoon to exchange semantic indexing
information in a Peer2Peer way to create a decentralized semantic search
engine... (even if there are big protocol scalability problems to
solve). Consider this high steam vaporware, but I believe that it will
make perfect sense to decentralize information searching capabilities to
avoid both central point of failure and central points of censorship in
the future.
Final words
-----------
If you reached this far by reading all sections, I was successful in
getting your attention and I think you are able to both understand the
importance of the Cocoon Project and distinguish most of the marketing
hype that surrounds XML and friends.
Just like you shouldn't care if somebody offers you a software that is
"ASCII compliant" or "ASCII based", you shouldn't care about "XML
compliant" or "XML based": it doesn't mean anything.
Cocoon uses XML as a core piece of its framework, but improves the model
to give you the tools you need and is designed to be flexible enough to
follow your needs as well as paradigm shifts that will happen in the
future.
Bibliography
------------
W3C - Technical Reports - http://www.w3.org/TR/
Tim Berners-Lee - Web Design Issues - http://www.w3.org/DesignIssues/
Tim Berners-Lee - Good URIs don't change -
http://www.w3.org/Provider/Style/URI
Jakob Nielsen - URL as UI - http://www.useit.com/alertbox/990321.html
Roy Fielding at alt. - HTTP/1.1 (RFC 2616) -
ftp://ftp.isi.edu/in-notes/rfc2616.txt
Legal
-----
Copyright (c) 2000 Stefano Mazzocchi. All rights reserved.
Permission to distribute this paper in any form is granted provided it
is not modified in any part. For further permissions contact the author.
----------------------------- cut here ------------------------------
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [RT] Cocoon Emotional Landscapes
Posted by Hans Ulrich Niedermann <ni...@isd.uni-stuttgart.de>.
Stefano Mazzocchi <st...@apache.org> writes:
> I was asked to write a white paper on why Cocoon is better than other
> web technologies. This is mostly targetted to managers and executives.
> Since it might help you to convince your boss, I'm posting it to this
> list.
>
> Any volunteer that translates this into the Cocoon Document DTD is
> welcome :)
Mostly done -> PM.
Uli
Re: [RT] Cocoon Emotional Landscapes
Posted by Hans Ulrich Niedermann <ni...@isd.uni-stuttgart.de>.
310026124542-0001@t-online.de (Mark Washeim) writes:
> on 10/11/00 11:22 PM, Stefano Mazzocchi at stefano@apache.org wrote:
>
> > I was asked to write a white paper on why Cocoon is better than other
> > web technologies. This is mostly targetted to managers and executives.
> > Since it might help you to convince your boss, I'm posting it to this
> > list.
> >
> > Any volunteer that translates this into the Cocoon Document DTD is
> > welcome :)
>
> I'll mark it up, if someone hasn't done so already.
Already done. (See my mail from Thursday ~03:00 CEST)
Uli
Re: [RT] Cocoon Emotional Landscapes
Posted by Mark Washeim <31...@t-online.de>.
on 10/11/00 11:22 PM, Stefano Mazzocchi at stefano@apache.org wrote:
> I was asked to write a white paper on why Cocoon is better than other
> web technologies. This is mostly targetted to managers and executives.
> Since it might help you to convince your boss, I'm posting it to this
> list.
>
> Any volunteer that translates this into the Cocoon Document DTD is
> welcome :)
I'll mark it up, if someone hasn't done so already.
I assume the DTD you refer to is:
document-v10.dtd?
> Also some spell checking and grammar correction.
Certainly!
> Yes, you're right, I'm a lazy butt. :)
>
Bastard :)
> This is included into the [RT] (random thoughts) series because it
> includes many references to things that are yet to come, either in this
> project or on the web as a general thing. Moreover, RT's are more fun to
> write :)
>
> ----------------------------- cut here ------------------------------
>
>
> Cocoon Emotional Landscapes
> or
> why you can't afford to miss Cocoon
>
> by
> Stefano Mazzocchi
> (stefano@apache.org)
>
>
>
> Introduction
> ------------
>
> Everybody talks about XML. XML here, XML there. All application servers
> support XML, everybody wants to do B2B using XML, web services using
> XML, even databases using XML.
>
> Should you care about it? Given the amount of hype, you can't afford to
> go around ignoring the argument, would be like ignoring the world wide
> web 10 years ago: a clear mistake. But why is this so for XML? What is
> this "magic" that XML seems to have to solve my problems? Isn't this
> another hype to change once again the IT infrastructure that you spent
> so much time implementing and fixing in the last few years? Isn't
> another way to spill money out of your pockets?
>
> If you ever asked yourself one of the above questions, this paper is for
> you. You won't find singing-and-dancing marketing crap, you won't find
> boring and useless feature lists, you won't find the usual acronym
> bombing or those good looking vaporware schemas that connect your
> databases to your coffee machines via CORBA or stuff like that.
>
> I'll explain you what the Apache Cocoon project is about and what we are
> doing to solve the problems that we encountered in our web engineering
> experiences, but from an executive perspective, yes, because we all had
> the problems of managing a web site, dealing with our colleages, rushing
> to the graphical guru to have the little GIF with the new title, or
> calling the web administrator at night because the database is returning
> errors without reasons.
>
> I was frustrated of seeing the best and most clever information
> technology ever invented (the web) ruined by the lack of engineering
> practices, tortured by those "let's-reinvent-the-wheel-once-again"
> craftmen that were great at doing their jobs as inviduals but that
> couldn't scale and imposed a growth saturation to the whole project.
>
> There had to be a better way of doing things.
>
>
> personal experience
> -------------------
>
> In 1998, I volunteered to create the documentation infrastructure for
> the java.apache.org project, which is composed by a bunch of different
> codebases, maintained by a bunch of different people, with different
> skills, different geographical locations and different degree of will
> and time to dedicate to the documentation effort.
>
> I designed the site look (which still remains the same), I designed the
> guidelines for HTML creation (which had to run on *all* HTML browsers
> that ever existed: tell that to your graphic designers and look at their
> faces!), I wrote the scripts to regenerate the site automatically taking
> documentation out of each project, and kicked butts around if they
> weren't following the guidelines.
>
> But pretty soon I realized no matter how great and well designed the
> system was, HTML was a problem: it was *not* designed for those kind of
> things. I looked at the main page (http://java.apache.org/) from the
> browser and you could clearly identify the areas of the screen: sidebar,
> topbar, news, status. But if you opened the HTML, boom: a nightmare or
> table tags and nesting and small little tricks to make the HTML appear
> the same on every browser.
>
> So I looked around for alternative technologies, but *all* of them were
> trying to add more complexity at the GUI level (Microsoft Frontpage,
> Macromedia Dreamweaver, Adobe GoLive, etc...) hoping to "hide" the
> design problems of HTML under a think layer of WYSIWYG looks.
>
> What you see is what you get.
>
> But what you see is all you've got.
>
> How can you tell your web server to "extract" the information from the
> sitebar? How can you have the news feeds out of a complex HTML page?
>
> Damn, it's easy for a human reader: just look at the page and it's very
> easy to distinguish between a sidebar, a banner, a news and a stock
> quote. Why is it so hard for a machine?
>
>
> The HTML model
> --------------
>
> HTML is a language that tells your browser how to "draw" things on its
> window. An image here, a letter there, a color down here. Nothing more.
> The browser doesn't have the "higher level" notion of "sidebar": it
> lacks the ability to perform "semantic analysis" on the HTML content.
>
> Semantic analysis? Yeah, it's the kind of thing the human brain is
> simply great at doing, while computer programs simply suck big time.
>
> So, with HTML, we went a step up and created a highly visual and
> appealing web of HTML content, but we went two steps back by removing
> all the higher level semantic information from the content itself.
>
> Ok, let's make an example... I think most of you have seen an HTML
> page... if not, here is an example:
>
> <html>
> <body>
> <p>Hi, I'm an HTML page</p>
> <p align="center">Written by Stefano</p>
> </body>
> </html>
>
> which says to the browser:
>
> - I'm a HTML page
> - I have a body
> - I have a paragraph
> - I contain the sentence "Hi, I'm an HTML page."
> - I contain the sentence "Written by Stefano"
>
> Suppose you are a chinese guy that doesn't understand our alphabet, try
> to answer the following question:
>
> who wrote the page?
>
> You can't perform semantic analysis, you are as blind as a web browser.
> The only thing you can do is draw it on the screen since this is what
> you were programmed to do. In other words, your semantic capacity is
> fixed to the drawing capabilities and a few other things (like linking),
> thus limited.
>
>
> Semantic markup
> ---------------
>
> Suppose I send you this page:
>
> <page>
> <author>sflkjoiuer</author>
> <content>
> <para>sofikdjflksj</para>
> </content>
> </page>
>
> now, who wrote the page? easy, you say, "sflkjoiuer" did. Good, but now
> I send you
>
> <dlkj>
> <ruijfl>sofikdjflksj</ruijfl>
> <wijlkjf>
> <oamkfkj>sflkjoiuer</oamkfkj>
> </wijlkjf>
> </dlkj>
>
> tell me, who wrote the page? You could guess by comparing the structure,
> but how do you know the two stuctures reflect the same semantic
> information?
>
> The above two pages are both XML documents.
>
> Are they going to help you? Are they doing to simplify your work? Are
> they going to simplify your problems?
>
> At this point, clearly not so, rather the opposite.
>
> So, I'm sure you are wondering, why did I spend the last two years
> writing an XML publishing framework? At the end of this paper, you'll be
> able to answer this question alone, so let's keep going.
>
>
> The XML Language
> ----------------
>
> XML is most of the times referred to as the "eXtensible Markup Language"
> specification. A fairly small yet complex specification that indicates
> how to write languages. It's a syntax. Nothing fancy at all. So
>
> <hello></hello>
>
> is correct, while
>
> <hello></hi>
>
> is not, but
>
> <hello><hi/></hello>
>
> is correct. That's more or less it.
>
> XML is the ASCII for the new millenium, it's a step forward from ASCII
> or UNICODE (the international extention to ASCII that includes all
> characters from all modern languages), it defined a "lingua franca" for
> textual languages.
>
> Ok, great, so now instead of having one uniform language with visual
> semantics (HTML) we have a babel of languages each with its own
> semantics. How this can possibly help me?
>
>
> XML transformations
> -------------------
>
> This was the point where I was more or less two years ago for
> java.apache.org: I could use XML and define my own semantics with
> <sidebar>, <news>, <status> and all that and I'm sure people would have
> found those XML documents much easier to write (since the XML syntax is
> very similar to the HTML one and very user friendly)... but I would have
> moved from "all browsers" to "no browser".
>
> And having a documentation that nobody can browse is totally useless.
>
> The turning point was the creation of the XSL specification which
> included a way to "transform" an XML page into something else. (it's
> more complex than this, but I'll skip the technical details).
>
> So now you have:
>
> XML page ---(transformation)--> HTML page
> ^
> |
> transformation rules
>
> that allowed me to write my pages in XML, create my "graphics" as
> tranformation rules and generate HTML pages on the fly directly from my
> web server.
>
> Cocoon 1.0 did exactly this.
>
>
> The model evolves
> -----------------
>
> If XML is a lingua franca, it means that XML software can work on almost
> anything without caring about what it is. So, if a cell phone requests
> the page, Cocoon just has to change transformation rules and send the
> WAP page to the phone. Or, if you want a nice PDF to printout your
> monthly report, you change the transformation rules and Cocoon creates
> the PDF for you, or the VRML, or the VoiceML, or your own proprietary
> B2B markup.
>
> Anything without changing the basic architecture that is simply based on
> the simple "angle braket" XML syntax.
>
>
> Separation of Concerns (SoC)
> ----------------------------
>
> Cocoon was not the first product to perform server side XML
> transformations, nor will be the last one (in a few years, these
> solutions will be the rule rather than the exception). What is the
> "plus" that the Cocoon project adds?
>
> I believe the most important Cocoon feature is SoC-based design.
>
> SoC is something that you've always been aware of: not everybody is
> equal, not everybody performs the same job with the same ability.
>
> It can be observed that separating people with common skills in
> different working groups increases productivity and reduces management
> costs, but only if the groups do not overlap and have clear "contracts"
> that define their operativity and their concerns.
>
> For a web publishing system, the Cocoon project uses what we call the
> "pyramid of contacts" which outlines four major concern areas and five
> contracts between them. Here is the picture:
>
> management
> / | \
> / | \
> style - content - logic
>
> Cocoon is "engineered" to provide you a way to isolate these four
> concern areas using just those 5 contracts, removing the contract
> between style and logic that has been bugging web site development since
> the beginning of the web.
>
> Why? because programmers and graphic people have very different skills
> and work habits... so, instead of creating GUIs to hide the things that
> can be harmful (like graphic to programmers or logic to designers),
> Cocoon allows you to separate the things into different files, allowing
> you to "seal" your working groups into separate virtual rooms connected
> with the other rooms only by those "pipes" (the contracts), that you
> give them from the management area.
>
> Let's have an example:
>
> <page>
> <content>
> <para>Today is <dynamic:today/></para>
> </content>
> </page>
>
> is written by the content writers and you give them the "contract" that
> states that the tag <dynamic:today/> prints out the time of the day when
> included in the page. Content writers don't care (nor should) about what
> language has been used for that, nor they can mess up with the
> programming logic that generates the content since it's stored in
> another part of the system they don't have access to.
>
> So <dynamic:today/> is the "logic - content" contract.
>
> At the same time, the structure of the page is given as a contract to
> the graphic designers who have to come up with the transformation rules
> that transform this structure in a language that the browser can
> understand (HTML, for example).
>
> So, the page structure is the "content - style" contract.
>
> As long as these contract don't change, the three areas can work in a
> completely parallel way without saturating the human resources used to
> manage them: costs decrease because time to market is reduced and
> maintenance costs is decreased because errors do not propagate out of
> the concern areas.
>
> For example, you can tell your designers to come up with a "Xmas look"
> for your web site, without even telling the other people: just switch
> the XMas transformation rules at XMas morning and you're done.... just
> imagine how painful it would be to do this on your web site day.
>
> With the Cocoon architecture it's a couple of line changes away.
>
>
> The Cocoon innovations
> ----------------------
>
> The technologies defined in the XML model are the base of everything,
> but many technologies and solutions were designed and invented by the
> Cocoon project:
>
> - the XSP language (eXtensible Server Pages)
> - the sitemap concept
> - the resource view concept
>
>
> The XSP language
> ----------------
>
> There were no technologies that allowed us to create the kind of
> "content - logic" separation outlined above, so we specified it. We used
> the JSP page compilation model as a starting point, but we designed XSP
> to be totally abstracted from programming language used.
>
> This means that you can implement the tags using your favorite language,
> without having to force your programmers to use a specific programming
> language. At the time of writing, only the Java programming language is
> implemented (being Cocoon written in Java), but it's easy to picture
> development of other language hooks for XSP once Cocoon receives more
> attention.
>
> Anyway, thanks to complete separation of concerns, the changes in the
> logic concern area don't impact the other areas and allow more
> flexibility in the human resource used in the project since programming
> languages will be easily interchanged and XSP is not connected to a
> particular implementation (the AxKit project implemented XSP directly in
> Perl)
>
>
> The Sitemap concept
> -------------------
>
> XSP allowed us to complete the second contract, but we have three more
> to go and all of them start from the site management area.
>
> Site managers are responsible for controlling the resources that are
> hosted on the site. A "resource" is not a file stored on a file system
> but the view of the data connected to a particular web address.
>
> For example,
>
> http://your.intranet.com/calendar/today
>
> is a "resource" but could be dynamically generated by information stored
> on your corporate database.
>
> The sitemap allows site administrators to "compose" the modules that
> collaborate to create a particular resource and connect them to the
> particular resource address. For example,
>
> <match pattern="/calendar/today">
> <generate type="calendar" src="today"/>
> <transform src="transformation/calendar2html"/>
> <serialize type="html"/>
> </match>
>
> or, supposing you want to connect with your Palm to the calendar or with
> Acrobat for printing:
>
> <match pattern="/calendar/today">
> <generate type="calendar" src="today"/>
> <select type="browser">
> <when test="palm">
> <transform src="transformation/calendar2palm"/>
> <serialize type="palm"/>
> </when>
> <when test="acrobat">
> <transform src="transformation/calendar2pdf"/>
> <serialize type="pdf"/>
> </when>
> <otherwise>
> <transform src="transformation/calendar2html"/>
> <serialize type="html"/>
> </otherwise>
> </select>
> </match>
>
> yes, it's that simple, the above is a real working example. Given the
> right logic components and transformation rules, the site administrators
> to just that: compose the modules to create web sites and web
> applications.
>
> Of course, there are situations where the logic involved in the
> componentization is much more complex than this, but the sitemap concept
> allows to finish the implementation of the five contracts without
> overlapping between the concern areas.
>
>
> The Resource View concept
> -------------------------
>
> The third big innovation of the Cocoon project is the notion of
> "resource views". It's kind of an abstract concept so I'd like to start
> with an example to explain the problem.
>
> A big XML myth is that a web of XML content would be easier to searching
> and index given the uniform syntax.
>
> This is simply dead wrong.
>
> As one of the first examples clearly showed, there is no way for a
> search engine to perform semantic analysis on something like
>
> <dlkj>
> <ruijfl>sofikdjflksj</ruijfl>
> <wijlkjf>
> <oamkfkj>sflkjoiuer</oamkfkj>
> </wijlkjf>
> </dlkj>
>
> the only useful thing would be to ask for all the web resources where
> "sofikdjflksj" is included into "ruijfl" tags... but if you think at the
> possible huge babel of XML languages that might appear in the next
> decades, this is a clear problem.
>
> The RDF (resource description framework) model is an effort that aims to
> reduce this problem by creating uniform semantics to "describe" any kind
> of information. For example, it could allow the author of this weird
> markup to indicate that
>
> <ruijfl>
>
> inherits the semantic meanings of <author>. So, if you search for
> "sofikdjflksj" as an <author>, it will be able to search between
> <ruijfl> as well.
>
> It will be a happy day when there will be enough RDF information on the
> web to allow such semantic-rich searching, it will correctly be a much
> better web for search and retrieval of information.
>
> The problem is that all other publishing systems except Cocoon "hide"
> this information inside the system, there is no standard way to "ask"
> for the original RDF-ized semantic content of the requested resource.
>
> There is no way to ask for a particular "view" of the resource.
>
> In Cocoon you can define "views" for each resource or group of
> resources: you can ask for the "content" view, or for the "schema" view
> (that returns you the structure of the document and the information to
> validate it), the "link" view that returns you the pages that are
> connected to this particular resource and so on.
>
> Resource views are a particular type of HTTP variants, but targetted for
> the yet-to-be-possible semantic indexing of content.
>
> Cocoon itself uses the view for its batch mode: it performs as a crawler
> and saves a snapshot of the site on disk, useful for creating offline
> documentation or CD-ROM snapshots of dynamic web sites.
>
>
> Cocoon present
> --------------
>
> The Cocoon project is currently discussing new features such as "content
> aggregation" that would simplify the creation of portal-like sites where
> content is aggregated from different sources into the same page.
>
> At the time of writing, the design has yet to solidity.
>
>
> Cocoon future
> -------------
>
> In the future, Cocoon will provide local semantic searching capabilities
> allowing you to gain immediate advantage of the time invested in
> creating highly semantic content for your site.
>
> I believe this is the only way to convince people to invest time and
> resources into creating a better content model for their local
> information. We still don't have any idea on how this will happen or how
> it will work, but I believe the Cocoon project has a major role in the
> promotion of the next web generation and semantic searching is a big
> part of it.
>
> We'll do whatever it takes to help the semantic web to exist.
>
> A further future goal is to allow Cocoon to exchange semantic indexing
> information in a Peer2Peer way to create a decentralized semantic search
> engine... (even if there are big protocol scalability problems to
> solve). Consider this high steam vaporware, but I believe that it will
> make perfect sense to decentralize information searching capabilities to
> avoid both central point of failure and central points of censorship in
> the future.
>
> Final words
> -----------
>
> If you reached this far by reading all sections, I was successful in
> getting your attention and I think you are able to both understand the
> importance of the Cocoon Project and distinguish most of the marketing
> hype that surrounds XML and friends.
>
> Just like you shouldn't care if somebody offers you a software that is
> "ASCII compliant" or "ASCII based", you shouldn't care about "XML
> compliant" or "XML based": it doesn't mean anything.
>
> Cocoon uses XML as a core piece of its framework, but improves the model
> to give you the tools you need and is designed to be flexible enough to
> follow your needs as well as paradigm shifts that will happen in the
> future.
>
> Bibliography
> ------------
>
> W3C - Technical Reports - http://www.w3.org/TR/
> Tim Berners-Lee - Web Design Issues - http://www.w3.org/DesignIssues/
> Tim Berners-Lee - Good URIs don't change -
> http://www.w3.org/Provider/Style/URI
> Jakob Nielsen - URL as UI - http://www.useit.com/alertbox/990321.html
> Roy Fielding at alt. - HTTP/1.1 (RFC 2616) -
> ftp://ftp.isi.edu/in-notes/rfc2616.txt
>
> Legal
> -----
>
> Copyright (c) 2000 Stefano Mazzocchi. All rights reserved.
>
> Permission to distribute this paper in any form is granted provided it
> is not modified in any part. For further permissions contact the author.
>
> ----------------------------- cut here ------------------------------
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Stefano Mazzocchi <st...@apache.org>.
Paul Russell wrote:
>
> On Tue, Oct 17, 2000 at 10:42:49PM +1000, Peter Donald wrote:
> > However I would love a list to bounce around random ideas and see where
> > they end up ;). Not sure what the charter for such a group would be - but
> > as I guess most would be re: web stuff so ??? ;)
>
> Depends on what the ideas are, I suppose. Most of mine concern
> what replaces the web as it stands at the moment, and most of
> stefanos seem to be along similar lines (although they take a
> different tack). I just want to get some of these things out
> into the open so that people who I trust to work in the best
> interests of everyone can build the architecture to support it
> without it being controlled by one company.
>
> The irony in all this is that I'm your architypical capitalist -
> I own a company for crying out loud. What I can't work out is
> why the other companies think the only way to make money is as a
> monopoly, rather than just by being the best.
Because a monopoly is easier to manage, easier to protect and lasts
longer :)
But don't worry: as long as Apache remains the leader provider of web
technologies, the web will remain as it is today.
We just have to make sure that corporations don't pollute us from the
inside or use us for their political games, and we keep innovating and
proposing alternative solutions as a whole group.
Yes, patents might prevent this from happening, but the US patent system
has been changed to allow individuals to submit evidences of previous
technology for 3 months... and a world-wide mirrored softare and mail
messages are very solid legal evidences of prior art.
So, let's keep up the good work on software here and compete on services
out there :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paul Russell <pa...@luminas.co.uk>.
On Tue, Oct 17, 2000 at 10:42:49PM +1000, Peter Donald wrote:
> However I would love a list to bounce around random ideas and see where
> they end up ;). Not sure what the charter for such a group would be - but
> as I guess most would be re: web stuff so ??? ;)
Depends on what the ideas are, I suppose. Most of mine concern
what replaces the web as it stands at the moment, and most of
stefanos seem to be along similar lines (although they take a
different tack). I just want to get some of these things out
into the open so that people who I trust to work in the best
interests of everyone can build the architecture to support it
without it being controlled by one company.
The irony in all this is that I'm your architypical capitalist -
I own a company for crying out loud. What I can't work out is
why the other companies think the only way to make money is as a
monopoly, rather than just by being the best.
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Peter Donald <pj...@cs.latrobe.edu.au>.
At 09:37 17/10/00 +0100, you wrote:
>I second that, and I'd like to add something more. I'm rapidly
>heading for paranoia regarding software patents and the like.
>I don't know about you lot, but I have a lot of ideas floating
>around that I simply don't have *time* to write down and/or
>explore. What worries me is that some commercial organisation
>could think of them in a few years time and claim them as theirs,
>which I *really* don't want to happen. Potentially world changing
>ideas should belong to *everyone* not a money making entity.
>
>Is it worth someone setting up a mailing list or something for
>just bouncing [RT]s around all day? There are a lot of visionaries
>on this list (most of the commiters for a start) and it seems to
>me that these people are just the kind of people to start such
>a list. If there's a list with all these ideas archived not only
>centrally but on a couple of thousand people's inboxes, nobody
>will be able to claim patents on anything sent to the list as
>there's already clearly a prior art.
>
>Thoughts?
Nice idea thou I am not sure how successful it will be in blocking patents.
All the major PITA patents clearly had prior art but got through. While
patents will soon (or currently are ?) forced to open up during application
stage there still needs someone to constantly watchdog them and then foot
the bill to go to court/through the process.
Some of the patents are clearly rediculous (ie nulls for terminating linked
lists is patented as is advertisements in interactive entertainmen) but
there are others less so and backed by companies willing to defend them.
Taking out those big fellas would be way to expensive a process i do
believe ;(
However I would love a list to bounce around random ideas and see where
they end up ;). Not sure what the charter for such a group would be - but
as I guess most would be re: web stuff so ??? ;)
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Ross Burton <ro...@lineone.net>.
On Tue, 17 Oct 2000, Paul Russell wrote:
> Is it worth someone setting up a mailing list or something for
> just bouncing [RT]s around all day? There are a lot of visionaries
> on this list (most of the commiters for a start) and it seems to
> me that these people are just the kind of people to start such
> a list. If there's a list with all these ideas archived not only
> centrally but on a couple of thousand people's inboxes, nobody
> will be able to claim patents on anything sent to the list as
> there's already clearly a prior art.
IIRC, there is a web site called shouldexist.org where this sort of this
can be discussed. Well, that is the plan... I've never tried it so I
don't know how well it works....
Ross Burton
RE: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paulo Gaspar <pa...@krankikom.de>.
I red that there is someone, somewhere, organizing an archive of
"prior art" to avoid just that. I will go back to you when I
remember the "someone" and the "somewhere".
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paul Russell [mailto:paulr@luminas.co.uk]On Behalf Of Paul Russell
> Sent: Tuesday, October 17, 2000 10:37
>
> ... I'm rapidly
> heading for paranoia regarding software patents and the like.
> I don't know about you lot, but I have a lot of ideas floating
> around that I simply don't have *time* to write down and/or
> explore. What worries me is that some commercial organisation
> could think of them in a few years time and claim them as theirs,
> which I *really* don't want to happen. Potentially world changing
> ideas should belong to *everyone* not a money making entity.
>
> Paul, looking slightly quizically at the EPO.
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paul Russell <pa...@luminas.co.uk>.
> So, please, add this to your vision: not only Cocoon is based on open
> standards, but it's developped in the open and everybody can have it for
> free and power their systems with it without having to pay a "semantic
> web tax" to a particular commercial company.
I second that, and I'd like to add something more. I'm rapidly
heading for paranoia regarding software patents and the like.
I don't know about you lot, but I have a lot of ideas floating
around that I simply don't have *time* to write down and/or
explore. What worries me is that some commercial organisation
could think of them in a few years time and claim them as theirs,
which I *really* don't want to happen. Potentially world changing
ideas should belong to *everyone* not a money making entity.
Is it worth someone setting up a mailing list or something for
just bouncing [RT]s around all day? There are a lot of visionaries
on this list (most of the commiters for a start) and it seems to
me that these people are just the kind of people to start such
a list. If there's a list with all these ideas archived not only
centrally but on a couple of thousand people's inboxes, nobody
will be able to claim patents on anything sent to the list as
there's already clearly a prior art.
Thoughts?
Paul, looking slightly quizically at the EPO.
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Carsten Ziegeler <cz...@sundn.de>.
I just updated the sitemap documentation a little bit (renamed Choosers and Filters)
and added the "raw" mails.
Next week I have more time to clean up the documentation further.
Carsten
> Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
> >
> > > Santiago Gala wrote
> > >
> > > I have not commit rights, but I would post this mail as is in the
> > > documents, linked from the sitemap documentation.
> > >
> > > It opens a new world of possibilities for cocoon I had never thought
> of,
> > > like virtual hosting, separate mounting of webapps, ...
> > >
> > > <snip>
> >
> > Yes, I agree. As soon as I have time I will update the docs with this
> stuff,
> > including the email and Giacomos explanations.
>
> +1000
>
> Thanks
>
> Giacomo
>
> >
> > Just give me a little bit time...
> >
> > Carsten
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> > Santiago Gala wrote
> >
> > I have not commit rights, but I would post this mail as is in the
> > documents, linked from the sitemap documentation.
> >
> > It opens a new world of possibilities for cocoon I had never thought of,
> > like virtual hosting, separate mounting of webapps, ...
> >
> > <snip>
>
> Yes, I agree. As soon as I have time I will update the docs with this stuff,
> including the email and Giacomos explanations.
+1000
Thanks
Giacomo
>
> Just give me a little bit time...
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Understanding mount (Testing root level mount points)
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Santiago Gala wrote
>
> I have not commit rights, but I would post this mail as is in the
> documents, linked from the sitemap documentation.
>
> It opens a new world of possibilities for cocoon I had never thought of,
> like virtual hosting, separate mounting of webapps, ...
>
> <snip>
Yes, I agree. As soon as I have time I will update the docs with this stuff,
including the email and Giacomos explanations.
Just give me a little bit time...
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Santiago Gala <sg...@hisitech.com>.
I have not commit rights, but I would post this mail as is in the
documents, linked from the sitemap documentation.
It opens a new world of possibilities for cocoon I had never thought of,
like virtual hosting, separate mounting of webapps, ...
Giacomo Pati wrote:
> Colin Britton wrote:
>
>>>> Can a map:mount be inside a map:select like this...
>>>
>> <snip/>
>>
>>> From the sitemap.xsl logicsheet there is no limitation on where a
>>> map:mount should be and thus are free to place it where you want.
>>
>> <snip/>
>>
>>> Well, haven't thought about replacing the root URI with different
>>> sitemaps but I'd like you to test it and report your experience on this
>>> list :)
>>
>> So here goes. The aim of my tests was to see how the sitemap mount function
>> could be used to simplfy the creation and management of cocoon2 based sites
>> and applications. We have a good size server (quad processor PIII server
>> with plenty of ram and HD) and wish to deploy multiple clents work and
>> multiple applications on the same box. Now we could (and will) setup
>> multiple http servers and therefore multiple servlet environments and
>> multiple Cocoon applications. But this creates a lot of admin and multiple
>> versions of items and all the heartache that comes with it.
>>
>> I wanted to see if we could solve the following problems within the cocoon
>> environment.
>>
>> 1) Simplify site construction
>> 2) Reduce risk of "bad' sitemap entries killing whole site
>> 3) Ease deployment of pre-built applications
>> 4) Keep sitemap files an understandable and manageable size
>>
>> The short answer is that the sitemap and in particular the mount function
>> does a good job of meeting my goals.
>
>
> What we allways thought of it should be but never were able to test it
> so far :)
>
>
>> My test was such.
>>
>> I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
>> A matcher and a selector. These two components allow me to select and direct
>> to mount two other site maps.
>>
>> These sub-sitemaps load the componants they need (which includes generators
>> and transformers etc...) and have the map elements for that
>> site/application.
>
>
> Take into account that sitemap components (generators, transformers,
> etc.) in a sitemap are accessible by a sub-sitemap by their names. This
> is due to the fact that each sitemap has its own SitemapComponentManager
> and they are arranged in the same hierarchical structure as the sitemaps
> are and thus knows which are their parent SitemapComponentManager and
> can ask it for a SitemapComponent it doesn't know about.
>
>
>> The benefit is that each sitemap is completely independant of each other and
>> any error in that sitemap does not kill any other sitemap. This seems to
>> work pretty well. I ran this up and deliberatly broke a sitemap and the
>> other one still ran.
>
>
> But usually you use the same SitemapComponents over and over again in
> your sub-sitemaps. And because you have a contract between the parent
> and sub sitemaps (the uri-prefix) you can deliver common
> SitemapComponents from the parent sitemap to your sub-sitemaps as well.
>
> Also note that if you break a sitemap all its sub-sitemaps are broken as
> well (because of the hierarchical arragement).
>
>
>> The benefit is I can build a seperate app or site on another machine, test
>> it offline and deploy it on the main server with minimal risk and
>> distruption. A huge win.
>
>
> This is why sub sitemaps were introduced: scalability.
>
> SIDENOTE: This is why there is an EntityResolver argument in the
> signature of the SitemapModelComponent interface. When a subsitemap is
> mounted the sitemap engine reports the uri-prefix and the context (src)
> to the calling Environment (changeContext method) so that
> SitemapComponent (i.e. URIMatcher) requesting a URI don't see the prefix
> and if for example a generator needs to resolve an src resource the
> EntityResolver (implemented by the calling Environment) is responsible
> to resolve that to the changed context the subsitep is in.
>
>
>> Here is my main sitemap. You will notice that I am using a selector that
>> matches on host name of the request, but any matcher or selector would work
>> at this point. I am mounting both sub-sitemaps at the root level.
>>
>> <?xml version="1.0"?>
>> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>> <!-- =========================== Components
>> ================================ -->
>> <map:components>
>> <map:matchers default="wildcard">
>> <map:matcher name="wildcard"
>> factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
>> </map:matchers>
>>
>> <map:selectors default="host">
>> <map:selector name="host"
>> factory="org.apache.cocoon.selection.HostSelectorFactory">
>> <host name="fee" value=www.foo.com/>
>> </map:selector>
>> </map:selectors>
>>
>> </map:components>
>> <!-- =========================== Pipelines
>> ================================= -->
>> <map:pipelines>
>> <map:pipeline>
>>
>> <map:select type="host">
>> <map:when test="fee">
>> <map:mount uri-prefix="" src="fee.xmap"/>
>> </map:when>
>> <map:otherwise>
>> <map:mount uri-prefix="" src="foo.xmap"/>
>> </map:otherwise>
>> </map:select>
>>
>> </map:pipeline>
>> </map:pipelines>
>> </map:sitemap>
>> <!-- end of file -->
>
>
> This is cool. Mounting different sitemaps on to the root URI :)
>
>
>> So this is a cool way to build out a cocoon2 app/site.
>>
>> Comments and ideas....
>
>
> Thanks for your investigations.
>
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Giacomo Pati <gi...@apache.org>.
Colin Britton wrote:
>
> > > Can a map:mount be inside a map:select like this...
> <snip/>
> > From the sitemap.xsl logicsheet there is no limitation on where a
> > map:mount should be and thus are free to place it where you want.
> <snip/>
> > Well, haven't thought about replacing the root URI with different
> > sitemaps but I'd like you to test it and report your experience on this
> > list :)
>
> So here goes. The aim of my tests was to see how the sitemap mount function
> could be used to simplfy the creation and management of cocoon2 based sites
> and applications. We have a good size server (quad processor PIII server
> with plenty of ram and HD) and wish to deploy multiple clents work and
> multiple applications on the same box. Now we could (and will) setup
> multiple http servers and therefore multiple servlet environments and
> multiple Cocoon applications. But this creates a lot of admin and multiple
> versions of items and all the heartache that comes with it.
>
> I wanted to see if we could solve the following problems within the cocoon
> environment.
>
> 1) Simplify site construction
> 2) Reduce risk of "bad' sitemap entries killing whole site
> 3) Ease deployment of pre-built applications
> 4) Keep sitemap files an understandable and manageable size
>
> The short answer is that the sitemap and in particular the mount function
> does a good job of meeting my goals.
What we allways thought of it should be but never were able to test it
so far :)
> My test was such.
>
> I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
> A matcher and a selector. These two components allow me to select and direct
> to mount two other site maps.
>
> These sub-sitemaps load the componants they need (which includes generators
> and transformers etc...) and have the map elements for that
> site/application.
Take into account that sitemap components (generators, transformers,
etc.) in a sitemap are accessible by a sub-sitemap by their names. This
is due to the fact that each sitemap has its own SitemapComponentManager
and they are arranged in the same hierarchical structure as the sitemaps
are and thus knows which are their parent SitemapComponentManager and
can ask it for a SitemapComponent it doesn't know about.
> The benefit is that each sitemap is completely independant of each other and
> any error in that sitemap does not kill any other sitemap. This seems to
> work pretty well. I ran this up and deliberatly broke a sitemap and the
> other one still ran.
But usually you use the same SitemapComponents over and over again in
your sub-sitemaps. And because you have a contract between the parent
and sub sitemaps (the uri-prefix) you can deliver common
SitemapComponents from the parent sitemap to your sub-sitemaps as well.
Also note that if you break a sitemap all its sub-sitemaps are broken as
well (because of the hierarchical arragement).
> The benefit is I can build a seperate app or site on another machine, test
> it offline and deploy it on the main server with minimal risk and
> distruption. A huge win.
This is why sub sitemaps were introduced: scalability.
SIDENOTE: This is why there is an EntityResolver argument in the
signature of the SitemapModelComponent interface. When a subsitemap is
mounted the sitemap engine reports the uri-prefix and the context (src)
to the calling Environment (changeContext method) so that
SitemapComponent (i.e. URIMatcher) requesting a URI don't see the prefix
and if for example a generator needs to resolve an src resource the
EntityResolver (implemented by the calling Environment) is responsible
to resolve that to the changed context the subsitep is in.
> Here is my main sitemap. You will notice that I am using a selector that
> matches on host name of the request, but any matcher or selector would work
> at this point. I am mounting both sub-sitemaps at the root level.
>
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <!-- =========================== Components
> ================================ -->
> <map:components>
> <map:matchers default="wildcard">
> <map:matcher name="wildcard"
> factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
> </map:matchers>
>
> <map:selectors default="host">
> <map:selector name="host"
> factory="org.apache.cocoon.selection.HostSelectorFactory">
> <host name="fee" value=www.foo.com/>
> </map:selector>
> </map:selectors>
>
> </map:components>
> <!-- =========================== Pipelines
> ================================= -->
> <map:pipelines>
> <map:pipeline>
>
> <map:select type="host">
> <map:when test="fee">
> <map:mount uri-prefix="" src="fee.xmap"/>
> </map:when>
> <map:otherwise>
> <map:mount uri-prefix="" src="foo.xmap"/>
> </map:otherwise>
> </map:select>
>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
> <!-- end of file -->
This is cool. Mounting different sitemaps on to the root URI :)
> So this is a cool way to build out a cocoon2 app/site.
>
> Comments and ideas....
Thanks for your investigations.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount (Testing root level mount points)
Posted by Colin Britton <cb...@centervilletech.com>.
> > Can a map:mount be inside a map:select like this...
<snip/>
> From the sitemap.xsl logicsheet there is no limitation on where a
> map:mount should be and thus are free to place it where you want.
<snip/>
> Well, haven't thought about replacing the root URI with different
> sitemaps but I'd like you to test it and report your experience on this
> list :)
So here goes. The aim of my tests was to see how the sitemap mount function
could be used to simplfy the creation and management of cocoon2 based sites
and applications. We have a good size server (quad processor PIII server
with plenty of ram and HD) and wish to deploy multiple clents work and
multiple applications on the same box. Now we could (and will) setup
multiple http servers and therefore multiple servlet environments and
multiple Cocoon applications. But this creates a lot of admin and multiple
versions of items and all the heartache that comes with it.
I wanted to see if we could solve the following problems within the cocoon
environment.
1) Simplify site construction
2) Reduce risk of "bad' sitemap entries killing whole site
3) Ease deployment of pre-built applications
4) Keep sitemap files an understandable and manageable size
The short answer is that the sitemap and in particular the mount function
does a good job of meeting my goals.
My test was such.
I build a main sitemap, for C2 to load This sitemap is the minimum it needs.
A matcher and a selector. These two components allow me to select and direct
to mount two other site maps.
These sub-sitemaps load the componants they need (which includes generators
and transformers etc...) and have the map elements for that
site/application.
The benefit is that each sitemap is completely independant of each other and
any error in that sitemap does not kill any other sitemap. This seems to
work pretty well. I ran this up and deliberatly broke a sitemap and the
other one still ran.
The benefit is I can build a seperate app or site on another machine, test
it offline and deploy it on the main server with minimal risk and
distruption. A huge win.
Here is my main sitemap. You will notice that I am using a selector that
matches on host name of the request, but any matcher or selector would work
at this point. I am mounting both sub-sitemaps at the root level.
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<!-- =========================== Components
================================ -->
<map:components>
<map:matchers default="wildcard">
<map:matcher name="wildcard"
factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
</map:matchers>
<map:selectors default="host">
<map:selector name="host"
factory="org.apache.cocoon.selection.HostSelectorFactory">
<host name="fee" value=www.foo.com/>
</map:selector>
</map:selectors>
</map:components>
<!-- =========================== Pipelines
================================= -->
<map:pipelines>
<map:pipeline>
<map:select type="host">
<map:when test="fee">
<map:mount uri-prefix="" src="fee.xmap"/>
</map:when>
<map:otherwise>
<map:mount uri-prefix="" src="foo.xmap"/>
</map:otherwise>
</map:select>
</map:pipeline>
</map:pipelines>
</map:sitemap>
<!-- end of file -->
So this is a cool way to build out a cocoon2 app/site.
Comments and ideas....
rgds
CB
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Colin Britton wrote:
>
> Can a map:mount be inside a map:select like this...
>From the sitemap.xsl logicsheet there is no limitation on where a
map:mount should be and thus are free to place it where you want.
> We have written a
> selector that matches on the host header so we can serve multiple
> domains/servers on the same cocoon instance and were just starting to look
> at sitemap structure for this.
>
> <map:match pattern="/">
> <map:select type="host">
> <map:when test="foo.com">
> <map:mount uri-prefix="/" src="foo_sitemap.xmap"/>
> </map:when>
> <map:otherwise>
> <map:mount uri-prefix="/" src="fee_sitemap.xmap"/>
> </map:otherwise>
> </map:select>
> </map:match>
Well, haven't thought about replacing the root URI with different
sitemaps but I'd like you to test it and report your experience on this
list :)
> do you want me to post the selector?
Sure, why not? Send it as zip to me (and please put some javadocs into
it to document the functionality and usage of your selector)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Colin Britton <cb...@centervilletech.com>.
Can a map:mount be inside a map:select like this... We have written a
selector that matches on the host header so we can serve multiple
domains/servers on the same cocoon instance and were just starting to look
at sitemap structure for this.
<map:match pattern="/">
<map:select type="host">
<map:when test="foo.com">
<map:mount uri-prefix="/" src="foo_sitemap.xmap"/>
</map:when>
<map:otherwise>
<map:mount uri-prefix="/" src="fee_sitemap.xmap"/>
</map:otherwise>
</map:select>
</map:match>
do you want me to post the selector?
rgds
CB
----- Original Message -----
From: "Giacomo Pati" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, March 22, 2001 6:21 AM
Subject: Re: [C2]: Understanding mount
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > I am currently playing a little bit with mounting subsitemaps.
> > After a while I got it working now, but I am still wondering
> > what the exact purpose of the attributes uri-prefix and src is.
> >
> > I used the following mount-example from the sitemap draft:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > </map:match>
> >
> > This generates the following source:
> >
> > return sitemapManager.invoke (environment,
> > substitute(listOfLists, "dist/"),
> > substitute(listOfLists, "dist/{1}"), true);
>
> The uri-prefix is the part that should be removed from the request URI.
> The engine will correctly check for a trailing slash (which you may
> write, of course)
>
> The src attribute is where the subsitemap is located. If it ends in a
> slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> value is used. A check-reload attribute can be used to determine if the
> modification date of the subsitemap file should be checked. A mount
> element I use looks like:
>
> <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> or
> <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> check-reload="no"/>
>
> Giacomo
>
> > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > source argument for the sitemap handler to load the new sitemap.
> > So if I try to load the resource "dist/hello" the sitemap
> > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > to loaded. And so on.
> >
> > So I assume from this, that the "src" attribute indicates the location
of the subsitemap.
> > This would lead to:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/"
src="dist/subsitemap.xmap"/>
> > </map:match>
> >
> > The "uri-prefix" seems to be the part which has to be removed from the
uri,
> > this means sending the request "dist/welcome" will remove "dist/" from
the
> > uri and only "welcome" is passed to the subsitemap.
> > So I could use
> > <map:match pattern="hallo">
> > <map:generate src="test.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > in the "dist/subsitemap.xmap" to match the request.
> >
> > This example above works fine. Am I using the attributes correcly?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] sitemap
Posted by Giacomo Pati <gi...@apache.org>.
John Morrison wrote:
>
> My (main) sitemap doesn't reload automatically - is there something I need
> to set somewhere?
Are you sure? The sitemap regenerates as a background thread, in the
mean time you'll be served from the old one. As soon as the new sitemap
is available it will be used instead of the old one.
> I'd also like to know what is possible with the sitemap - is there any
> documents which describe what's there and what's intended in the future?
Well, indead we could have used some more docs. You'll find pieces
scattered around in the repository. The original proposal is
xdocs/draft/sitemap-working-draft.xmap and others are in the xdocs.
You'll get html version if you do a build docs (or alike)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2] sitemap
Posted by John Morrison <jo...@ntlworld.com>.
My (main) sitemap doesn't reload automatically - is there something I need
to set somewhere?
I'd also like to know what is possible with the sitemap - is there any
documents which describe what's there and what's intended in the future?
Thanks,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> Thank you, Giacomo, for the clearification.
>
> Should we add your explanation to the "sitemap-working-draft.xmap"
> and update the examples there?
What ever you like to document is *very* welcome :)
Giacomo
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: giacomo@ynes.de [mailto:giacomo@ynes.de]
> > Gesendet: Donnerstag, 22. Marz 2001 12:21
> > An: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2]: Understanding mount
> >
> >
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi,
> > >
> > > I am currently playing a little bit with mounting subsitemaps.
> > > After a while I got it working now, but I am still wondering
> > > what the exact purpose of the attributes uri-prefix and src is.
> > >
> > > I used the following mount-example from the sitemap draft:
> > >
> > > <map:match pattern="dist/*">
> > > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > > </map:match>
> > >
> > > This generates the following source:
> > >
> > > return sitemapManager.invoke (environment,
> > > substitute(listOfLists, "dist/"),
> > > substitute(listOfLists, "dist/{1}"), true);
> >
> > The uri-prefix is the part that should be removed from the request URI.
> > The engine will correctly check for a trailing slash (which you may
> > write, of course)
> >
> > The src attribute is where the subsitemap is located. If it ends in a
> > slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> > value is used. A check-reload attribute can be used to determine if the
> > modification date of the subsitemap file should be checked. A mount
> > element I use looks like:
> >
> > <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> > or
> > <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> > check-reload="no"/>
> >
> > Giacomo
> >
> > > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > > source argument for the sitemap handler to load the new sitemap.
> > > So if I try to load the resource "dist/hello" the sitemap
> > > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > > to loaded. And so on.
> > >
> > > So I assume from this, that the "src" attribute indicates the
> > location of
> > the subsitemap.
> > > This would lead to:
> > >
> > > <map:match pattern="dist/*">
> > > <map:mount uri-prefix="dist/" src
> > ="dist/subsitemap.xmap"/>
> > > </map:match>
> > >
> > > The "uri-prefix" seems to be the part which has to be removed from the
> > uri,
> > > this means sending the request "dist/welcome" will remove "dist/" from
> > the
> > > uri and only "welcome" is passed to the subsitemap.
> > > So I could use
> > > <map:match pattern="hallo">
> > > <map:generate src="test.xml"/>
> > > <map:serialize type="xml"/>
> > > </map:match>
> > > in the "dist/subsitemap.xmap" to match the request.
> > >
> > > This example above works fine. Am I using the attributes correcly?
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > ================================================================
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Understanding mount
Posted by Carsten Ziegeler <cz...@sundn.de>.
Thank you, Giacomo, for the clearification.
Should we add your explanation to the "sitemap-working-draft.xmap"
and update the examples there?
Carsten
> -----Ursprungliche Nachricht-----
> Von: giacomo@ynes.de [mailto:giacomo@ynes.de]
> Gesendet: Donnerstag, 22. Marz 2001 12:21
> An: cocoon-dev@xml.apache.org
> Betreff: Re: [C2]: Understanding mount
>
>
>
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > I am currently playing a little bit with mounting subsitemaps.
> > After a while I got it working now, but I am still wondering
> > what the exact purpose of the attributes uri-prefix and src is.
> >
> > I used the following mount-example from the sitemap draft:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src="dist/{1}"/>
> > </map:match>
> >
> > This generates the following source:
> >
> > return sitemapManager.invoke (environment,
> > substitute(listOfLists, "dist/"),
> > substitute(listOfLists, "dist/{1}"), true);
>
> The uri-prefix is the part that should be removed from the request URI.
> The engine will correctly check for a trailing slash (which you may
> write, of course)
>
> The src attribute is where the subsitemap is located. If it ends in a
> slash "sitemap.xmap" is appended to find the sitemap otherwise the src
> value is used. A check-reload attribute can be used to determine if the
> modification date of the subsitemap file should be checked. A mount
> element I use looks like:
>
> <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
> or
> <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
> check-reload="no"/>
>
> Giacomo
>
> > The third argument ("substitute(listOfLists, "dist/{1}")") is the
> > source argument for the sitemap handler to load the new sitemap.
> > So if I try to load the resource "dist/hello" the sitemap
> > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> > to loaded. And so on.
> >
> > So I assume from this, that the "src" attribute indicates the
> location of
> the subsitemap.
> > This would lead to:
> >
> > <map:match pattern="dist/*">
> > <map:mount uri-prefix="dist/" src
> ="dist/subsitemap.xmap"/>
> > </map:match>
> >
> > The "uri-prefix" seems to be the part which has to be removed from the
> uri,
> > this means sending the request "dist/welcome" will remove "dist/" from
> the
> > uri and only "welcome" is passed to the subsitemap.
> > So I could use
> > <map:match pattern="hallo">
> > <map:generate src="test.xml"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > in the "dist/subsitemap.xmap" to match the request.
> >
> > This example above works fine. Am I using the attributes correcly?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Understanding mount
Posted by Giacomo Pati <gi...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> I am currently playing a little bit with mounting subsitemaps.
> After a while I got it working now, but I am still wondering
> what the exact purpose of the attributes uri-prefix and src is.
>
> I used the following mount-example from the sitemap draft:
>
> <map:match pattern="dist/*">
> <map:mount uri-prefix="dist/" src="dist/{1}"/>
> </map:match>
>
> This generates the following source:
>
> return sitemapManager.invoke (environment,
> substitute(listOfLists, "dist/"),
> substitute(listOfLists, "dist/{1}"), true);
The uri-prefix is the part that should be removed from the request URI.
The engine will correctly check for a trailing slash (which you may
write, of course)
The src attribute is where the subsitemap is located. If it ends in a
slash "sitemap.xmap" is appended to find the sitemap otherwise the src
value is used. A check-reload attribute can be used to determine if the
modification date of the subsitemap file should be checked. A mount
element I use looks like:
<map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
or
<map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
check-reload="no"/>
Giacomo
> The third argument ("substitute(listOfLists, "dist/{1}")") is the
> source argument for the sitemap handler to load the new sitemap.
> So if I try to load the resource "dist/hello" the sitemap
> "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
> "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
> to loaded. And so on.
>
> So I assume from this, that the "src" attribute indicates the location of the subsitemap.
> This would lead to:
>
> <map:match pattern="dist/*">
> <map:mount uri-prefix="dist/" src="dist/subsitemap.xmap"/>
> </map:match>
>
> The "uri-prefix" seems to be the part which has to be removed from the uri,
> this means sending the request "dist/welcome" will remove "dist/" from the
> uri and only "welcome" is passed to the subsitemap.
> So I could use
> <map:match pattern="hallo">
> <map:generate src="test.xml"/>
> <map:serialize type="xml"/>
> </map:match>
> in the "dist/subsitemap.xmap" to match the request.
>
> This example above works fine. Am I using the attributes correcly?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2]: Understanding mount
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
I am currently playing a little bit with mounting subsitemaps.
After a while I got it working now, but I am still wondering
what the exact purpose of the attributes uri-prefix and src is.
I used the following mount-example from the sitemap draft:
<map:match pattern="dist/*">
<map:mount uri-prefix="dist/" src="dist/{1}"/>
</map:match>
This generates the following source:
return sitemapManager.invoke (environment,
substitute(listOfLists, "dist/"),
substitute(listOfLists, "dist/{1}"), true);
The third argument ("substitute(listOfLists, "dist/{1}")") is the
source argument for the sitemap handler to load the new sitemap.
So if I try to load the resource "dist/hello" the sitemap
"dist/hello/sitemap.xmap" is tried to loaded. When I try to load
"dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
to loaded. And so on.
So I assume from this, that the "src" attribute indicates the location of the subsitemap.
This would lead to:
<map:match pattern="dist/*">
<map:mount uri-prefix="dist/" src="dist/subsitemap.xmap"/>
</map:match>
The "uri-prefix" seems to be the part which has to be removed from the uri,
this means sending the request "dist/welcome" will remove "dist/" from the
uri and only "welcome" is passed to the subsitemap.
So I could use
<map:match pattern="hallo">
<map:generate src="test.xml"/>
<map:serialize type="xml"/>
</map:match>
in the "dist/subsitemap.xmap" to match the request.
This example above works fine. Am I using the attributes correcly?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2]: Possible Bug in mounting subsitemaps
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hello,
using the following mount-example from the sitemap draft:
<map:match pattern="dist/*">
<map:mount uri-prefix="dist/{1}" src="dist/{1}"/>
</map:match>
the following source is generated:
return sitemapManager.invoke (environment,
substitute(listOfLists, "dist/"),
substitute(listOfLists, "dist/{1}"), true);
The third argument ("substitute(listOfLists, "dist/{1}")") is the
source argument for the sitemap handler to load the new sitemap.
So if I try to load the resource "dist/hello" the sitemap
"dist/hello/sitemap.xmap" is tried to loaded. When I try to load
"dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
to loaded.
Is this the desired behaviour? I thought using the mount above
always tries to load the same sitemap "dist/sitemap.xmap".
Regards
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
RE: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Separation of concerns: I am assuming Cocoon will create the needs, thus
> a market and people will fill that.
>
> Anyway, it might be closer than you think ;-)
Yes, I already saw Cocoon being mentioned several times in the CMS-List.
>
> Hmmmm, what if that frontpage is an open source project as well <hint,
> hint> ;-)
I would like to see that. There is a lot to fix on that one.
(Example: he keeps changing what he shouldn't.)
> > I really find it hard to believe that the big sharks will be able to
> > close the CMS market on proprietary standards. One reason is that the
> > credibility of most big CMSs is going trough a all time low.
>
> I agree, but, we need to be careful... something these things happen
> without even noticing...
Yes... Big Brother keeps watching for an opportunity.
Paulo
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Stefano Mazzocchi <st...@apache.org>.
Paulo Gaspar wrote:
>
> Hi Stefano,
>
> Cocoon sure can play a very important role there, but it has a lot to
> evolve in that direction. The problem is still the lack of easy-to-use
> visual design tools and all those bells and whistles.
Separation of concerns: I am assuming Cocoon will create the needs, thus
a market and people will fill that.
Anyway, it might be closer than you think ;-)
> Fact is, most of the web designers at my employer do not go that far
> on text-editing HTML. Dreamweaver rules there. And I guess we are not
> the only ones.
No, not the only one by far. This is what I count on: people will need
these tools so bad they will emerge almost by themselves.
> And the fact is that many really good designers in terms of graphic
> look & style are not good at all on the more technical stuff. Still,
> the look of a site is damn important and we can not waste the
> contribution of those guys.
Totally.
> Now, XSLT is hard even for many designers that know HTML well. XSLT is
> hard even for some programmers. And there is no good visual tool to
> deal with it. I am not even going to start talking about other stuff.
I am :)
> On the other hand, open standards sell. So:
> - Maybe the big CMS sharks will start this whole "semantic" process
> using open standards like XML, XSLT, RDF and so on;
> - And maybe FrontPage and DreamWeaver will start doing some XSLT and
> even some RDF in order to work together with those CMSs;
> - And then, maybe Cocoon really spreads around because it will be a
> powerful and free open source CMS that uses those open standards
> too... which means that people will be able to use those future
> versions of Dreamweaver and FrontPage to cover the "visual design"
> need.
>
> Imagine... M$ FrontPage easing the spread of Cocoon!
> I am eager to see if that really happens.
> =;o)
Hmmmm, what if that frontpage is an open source project as well <hint,
hint> ;-)
> I really find it hard to believe that the big sharks will be able to
> close the CMS market on proprietary standards. One reason is that the
> credibility of most big CMSs is going trough a all time low.
I agree, but, we need to be careful... something these things happen
without even noticing...
> Customers will demand open standards to have a way out when something
> goes wrong. (Ok, they will be in deep sh*t anyway, but perception
> rules.)
I totally agree with this.
> So, I am optimist.
> =:o)
> Have fun,
you too :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
RE: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Stefano,
Cocoon sure can play a very important role there, but it has a lot to
evolve in that direction. The problem is still the lack of easy-to-use
visual design tools and all those bells and whistles.
Fact is, most of the web designers at my employer do not go that far
on text-editing HTML. Dreamweaver rules there. And I guess we are not
the only ones.
And the fact is that many really good designers in terms of graphic
look & style are not good at all on the more technical stuff. Still,
the look of a site is damn important and we can not waste the
contribution of those guys.
Now, XSLT is hard even for many designers that know HTML well. XSLT is
hard even for some programmers. And there is no good visual tool to
deal with it. I am not even going to start talking about other stuff.
On the other hand, open standards sell. So:
- Maybe the big CMS sharks will start this whole "semantic" process
using open standards like XML, XSLT, RDF and so on;
- And maybe FrontPage and DreamWeaver will start doing some XSLT and
even some RDF in order to work together with those CMSs;
- And then, maybe Cocoon really spreads around because it will be a
powerful and free open source CMS that uses those open standards
too... which means that people will be able to use those future
versions of Dreamweaver and FrontPage to cover the "visual design"
need.
Imagine... M$ FrontPage easing the spread of Cocoon!
I am eager to see if that really happens.
=;o)
I really find it hard to believe that the big sharks will be able to
close the CMS market on proprietary standards. One reason is that the
credibility of most big CMSs is going trough a all time low.
Customers will demand open standards to have a way out when something
goes wrong. (Ok, they will be in deep sh*t anyway, but perception
rules.)
So, I am optimist.
=:o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Monday, October 16, 2000 11:47
>
> Paulo,
>
> we are in deep resonation and I think it's great.
>
> I also hope this project can use this vision to pave the yellow brick
> road so that no commercial company becomes the owner of this semantic
> web.
>
> Imagine a world where a commercial company XXX has 80% of the market for
> these "semantic sites": it would take two seconds for big companies that
> own the web client side (browsers) to buy them and make a parallel
> "semantic browsing experience" proprietary... possibly polluting the
> HTTP protocol and locking in proprietary extensions.
>
> So, please, add this to your vision: not only Cocoon is based on open
> standards, but it's developped in the open and everybody can have it for
> free and power their systems with it without having to pay a "semantic
> web tax" to a particular commercial company.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
Re: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Stefano Mazzocchi <st...@apache.org>.
Paulo Gaspar wrote:
>
> I think Stefano is damn right.
> *** That is the reason I keep lurking in this list. ***
>
> Considering the currently available web design tools and my employer
> commercial needs, I am using different technology to build our
> publishing/CM system.
>
> I am not even going to talk why I prefer other solutions now and what
> I think to be good or bad in Cocoon. Except that "semantic searching"
> is the potential key advantage of Cocoon.
>
> In the future, XML based technologies are the way to go, mostly
> because of "semantic searching".
>
> Many people try to see it happening with a global standards
> initiative. However, I agree that starting with a W3C imposed
> standard is bound to fail. And the poor reception of RDF - outside
> academic circles - is a sign of that.
>
> But there are other ways. Especially the CMS way.
>
> More and more organizations are using Web technologies to manage and
> publish information. The more they do it the more they want to do it
> in a systematic way. And that is why there is so much demand for CMS
> (Content Management System).
>
> Semantic Search is a precious feature of CMS. When you keep a large
> amount of published content, you have to maintain both data and its
> formatting. This means that you have to, not only create, but to
> update and fix published data and layout - whish also implies that
> you will have to search whatever data and layout instances you want
> to update or fix.
>
> The commercial evolution of CMSs will ensure the creation of tools
> to search both instances of data and layout, even if that means the
> use of layout (template) and data publishing mechanisms that are
> easier to search/parse - as XSLT, XSQL and other XML derived
> technologies. Analyzing structure (which RDF tries to help with)
> comes next on the wish list.
>
> At first, only the most advanced CM systems will include all these
> features. Since standards openness has strong commercial advantages
> (besides all the others), these features will probably be based on
> standards like the above mentioned XML, XSLT, XHTML, RDF, etc.
>
> Then, we will not have yet a "semantic web" but we will have a few
> "semantic sites" - for those organizations that can pay those tools.
>
> As CM systems and related tools get more popularized (it happens
> with all technology) there will be more and more "semantic sites".
>
> Maybe not all the "semantic sites" then will be built using full
> fledged CMSs. However they will probably be built with versions of
> Dreamweaver or FrontPage supporting XHTML, XML data publishing,
> XSLT template design, RDF site description, etc.
>
> Remember, tools like Dreamweaver and FrontPage will evolve to be
> able to integrate with full fledged CM Systems - big customers -
> or compete with them - in the smaller ones.
>
> When these "semantic sites" reach a critical mass, that is when the
> stronger global "semantic web" initiatives will start popping up -
> maybe a whole new generation of search engines or a whole new
> class of navigation tools.
>
> And after those initiatives start popping up, that is when everybody
> will try to jump into the Semantic Web wagon.
>
> To me, this sounds quite reasonable.
Paulo,
we are in deep resonation and I think it's great.
I also hope this project can use this vision to pave the yellow brick
road so that no commercial company becomes the owner of this semantic
web.
Imagine a world where a commercial company XXX has 80% of the market for
these "semantic sites": it would take two seconds for big companies that
own the web client side (browsers) to buy them and make a parallel
"semantic browsing experience" proprietary... possibly polluting the
HTTP protocol and locking in proprietary extensions.
So, please, add this to your vision: not only Cocoon is based on open
standards, but it's developped in the open and everybody can have it for
free and power their systems with it without having to pay a "semantic
web tax" to a particular commercial company.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
[C2]: Problems with Xalan2 / XPathAPI
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hello,
after a successful update to the latest cocoon release, we have problems with the org.apache.cocoon.xml.xpath.XPathAPI class:
A method-call XPathAPI.selectSingleNode(testFragment, "test") returns null for the following fragment:
<test>
<a/>
</test>
"testFragment" is a DocumentFragment containing the "test"-node.
Changing the call to XPathAPI.selectSingleNode(testFragment, "*[local-nam()='test']") returns the correct node.
Is this a bug in the new Xalan2 code?
Regards
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
------------------------------------------------------------------------------------------
...this mail was scanned for viruses by mailserver...
RE: [RT] Cocoon Emotional Landscapes - semantic searching
Posted by Paulo Gaspar <pa...@krankikom.de>.
I think Stefano is damn right.
*** That is the reason I keep lurking in this list. ***
Considering the currently available web design tools and my employer
commercial needs, I am using different technology to build our
publishing/CM system.
I am not even going to talk why I prefer other solutions now and what
I think to be good or bad in Cocoon. Except that "semantic searching"
is the potential key advantage of Cocoon.
In the future, XML based technologies are the way to go, mostly
because of "semantic searching".
Many people try to see it happening with a global standards
initiative. However, I agree that starting with a W3C imposed
standard is bound to fail. And the poor reception of RDF - outside
academic circles - is a sign of that.
But there are other ways. Especially the CMS way.
More and more organizations are using Web technologies to manage and
publish information. The more they do it the more they want to do it
in a systematic way. And that is why there is so much demand for CMS
(Content Management System).
Semantic Search is a precious feature of CMS. When you keep a large
amount of published content, you have to maintain both data and its
formatting. This means that you have to, not only create, but to
update and fix published data and layout - whish also implies that
you will have to search whatever data and layout instances you want
to update or fix.
The commercial evolution of CMSs will ensure the creation of tools
to search both instances of data and layout, even if that means the
use of layout (template) and data publishing mechanisms that are
easier to search/parse - as XSLT, XSQL and other XML derived
technologies. Analyzing structure (which RDF tries to help with)
comes next on the wish list.
At first, only the most advanced CM systems will include all these
features. Since standards openness has strong commercial advantages
(besides all the others), these features will probably be based on
standards like the above mentioned XML, XSLT, XHTML, RDF, etc.
Then, we will not have yet a "semantic web" but we will have a few
"semantic sites" - for those organizations that can pay those tools.
As CM systems and related tools get more popularized (it happens
with all technology) there will be more and more "semantic sites".
Maybe not all the "semantic sites" then will be built using full
fledged CMSs. However they will probably be built with versions of
Dreamweaver or FrontPage supporting XHTML, XML data publishing,
XSLT template design, RDF site description, etc.
Remember, tools like Dreamweaver and FrontPage will evolve to be
able to integrate with full fledged CM Systems - big customers -
or compete with them - in the smaller ones.
When these "semantic sites" reach a critical mass, that is when the
stronger global "semantic web" initiatives will start popping up -
maybe a whole new generation of search engines or a whole new
class of navigation tools.
And after those initiatives start popping up, that is when everybody
will try to jump into the Semantic Web wagon.
To me, this sounds quite reasonable.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, October 13, 2000 23:38
>
> Peter Donald wrote:
> >
> >
> > do you really think there will ever be semantic searching?
>
> Yes, I do. This whole project is nothing but the liftoff platform for
> the semantic rocket. :)
>
Re: [RT] Cocoon Emotional Landscapes
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> >This is where I see the parallel: Cocoon and friends are now what the
> >web was 10 years ago, only with much more hype attached due to the XML
> >label.
>
> I agree
>
> >It will take another 4 years for XML to really take off and create the
> >critical mass to starting having semantic searching.
>
> do you really think there will ever be semantic searching?
Yes, I do. This whole project is nothing but the liftoff platform for
the semantic rocket. :)
I know you guys don't see this yet, I know.
I'll reveal more about this in my ApacheCON 2000 speech :)
(that I will make available right after the conference to everybody thru
the site and even, if you like, included in the distribution as I did
for the last speech).
> After working on it for a while I have basically decided that it
> wont ever happen.
Believe me, I entirely know your feeling about this, but something deep
inside tells me something and shows me the way.... you know I have a
strange ability to see where the wind will blow before it starts
blowing.
> I looked at RDF and thou - naah too complex which means your basically
> left in same situation you are in now.
Yep, but please answer my question: would XML publishing have sense
without a solid and portable transformation capability?
Now, does RDF makes sense for the semantic web without XXX?
The problem is defining what XXX is, but the parallel is strong: both
XML and RDF are way too general to mean something, you need more stuff
on top.
The RDF model has a weak RDFSchema on top that is highly overlapping
with XMLSchema with features and highly rejected by people because of
its complexity and apparent uselessness.
Just like you're doing now.
But semantic searching is too important to let the idea die.
> Basic textual analyisis and hit n miss datamining
> - is there any reason to believe this will change?
No, but here we are talking about the biggest collection of coherently
formatted and heavily hyperlined structured text in the history of
mankind.
It would make ancient Alexandria look a elemntary school library.
It's not just text anymore, so regular expressions and friends are poor
man tools compared to even basic contextual searching or even something
as simple as mechanical semantic inference.
No AI will be required, just a good strategy and some luck.
> I can't see Joe
> Six-pack conforming and maintaing correct meta information and considering
> most of the web is made up of our friendly neighbourhood Joes - unless we
> move to corporate web - I can't see it happening. What do you see that
> makes you think otherwise ?
Because Cocoon3 will give them the ability to perform semantic searches
on their local sites: Joe Six-pack will have to use text-based searching
for its site and loose market if others provide a much more efficient
semantic search.
Don't get me wrong: I do share your vision about what RDF and friends
are today, but I'm also aware of the fact that in a few decades the
amount of available information on the web will be so huge and
(hopefully) coherently organized that textual searches will be like
searching for textual strings in a library of images: useless.
Imagine a world of Cocoons and a web with thousands of different
user-agents and file formats that grows exponentially every year: how
can something like Google keep up with it?
The whole search experience must be redesigned from scratch.
And this is want I want to do with Cocoon3.
If you want to see it happening and help making the history of
technology, just stick around for the next couple of years :)
Oh, yeah, last thing: try to stop me :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [RT] Cocoon Emotional Landscapes
Posted by Peter Donald <pj...@cs.latrobe.edu.au>.
>This is where I see the parallel: Cocoon and friends are now what the
>web was 10 years ago, only with much more hype attached due to the XML
>label.
I agree
>It will take another 4 years for XML to really take off and create the
>critical mass to starting having semantic searching.
do you really think there will ever be semantic searching? After working on
it for a while I have basically decided that it wont ever happen. I looked
at RDF and thou - naah too complex which means your basically left in same
situation you are in now. Basic textual analyisis and hit n miss datamining
- is there any reason to believe this will change ? I can't see Joe
Six-pack conforming and maintaing correct meta information and considering
most of the web is made up of our friendly neighbourhood Joes - unless we
move to corporate web - I can't see it happening. What do you see that
makes you think otherwise ?
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [RT] Cocoon Emotional Landscapes
Posted by Matt Sergeant <ma...@sergeant.org>.
> > All of that is, I think, fairly debatable. Handlers can be chained
> > (although filtering isn't built in, but you can store in the notes table
> > to emulate filtering in Apache 1.x). And sure it could support views. It
> > depends what your module does, and how it interprets configuration options
> > you supply. If you like I can translate your example sitemap to an AxKit
> > equivalent to show how this can work with Apache 1.x's current config
> > system.
>
> Please do.
First of all, you must understand I know nothing of how Cocoon operates,
so the terms used in the sitemap are not familiar to me. I'm merely
representing something similar in my opinion. Feel free to shoot me down
in flames if my assumptions are incorrect.
Cocoon Sitemap Version:
<match pattern="/calendar/today">
<generate type="calendar" src="today"/>
<select type="browser">
<when test="palm">
<transform src="transformation/calendar2palm"/>
<serialize type="palm"/>
</when>
<when test="acrobat">
<transform src="transformation/calendar2pdf"/>
<serialize type="pdf"/>
</when>
<otherwise>
<transform src="transformation/calendar2html"/>
<serialize type="html"/>
</otherwise>
</select>
</match>
AxKit Version (in httpd.conf or .htaccess file):
<LocationMatch /calendar/today>
# following assumes generate type="calendar" could be done as an XSP
# again, I don't know what that directive really means so I'm guessing
AxAddProcessor application/x-xsp .
<AxMediaType handheld>
AxAddProcessor text/xsl transformation/calendar2palm
</AxMediaType>
<AxMediaType print>
AxAddProcessor text/xsl transformation/calendar2pdf
</AxMediaType>
<AxMediaType #default>
AxAddProcessor text/xsl transformation/calendar2html
</AxMediaType>
</LocationMatch>
I'm sure much more complex layouts are possible with a sitemap model, and
someone has written a Cocoon sitemap parser for AxKit (but they haven't
released it to the public yet), so you do have the ability to unplug this
method of working for something else should you so desire, but I tend to
think thats a YAGTNI thing compared with working with what we've given
users. Of course the answer to whether thats true or not is in the future
:-)
Have fun,
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: [RT] Cocoon Emotional Landscapes
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> On Thu, 12 Oct 2000, Stefano Mazzocchi wrote:
>
> > Matt Sergeant wrote:
> > >
> > > > - the XSP language (eXtensible Server Pages)
> > > > - the sitemap concept
> > > > - the resource view concept
> > >
> > > My only gripe would be that Cocoon somehow invented these
> > > concepts. DataChannel invented XSP, the sitemap "concept" is built into
> > > Apache (via <Location> tags and options between those tags)
> >
> > The "cocoon sitemap" concept is that you compose the pipelines using
> > modules.
> >
> > For sure it takes from the Apache sitemap, but Apache sitemaps are based
> > on URI matching only, don't have module chaining, don't have the notion
> > of views, don't have a bunch of other things.
>
> All of that is, I think, fairly debatable. Handlers can be chained
> (although filtering isn't built in, but you can store in the notes table
> to emulate filtering in Apache 1.x). And sure it could support views. It
> depends what your module does, and how it interprets configuration options
> you supply. If you like I can translate your example sitemap to an AxKit
> equivalent to show how this can work with Apache 1.x's current config
> system.
Please do.
> > And they are not compiled but interpreted.
>
> Dubious. httpd.conf is read at startup time, and values sent to the
> respective modules, and the values stored in an apache table
> structure. htaccess files are slightly different, of course.
I'm sure you know the meaning of "compiling" something: httpd.conf is
*NOT* compiled into code, that's not dubious at all!
> > There is huge difference between Cocoon sitemaps and Apache conf file.
>
> Like I said though, innovation, not invention.
well, I disagree, but I really don't care.
> > > and resource
> > > views are certainly available in other application servers (before Cocoon
> > > ever existed), MediaSurface comes to mind. Innovative, not inventive,
> > > IMHO.
> >
> > Like I wrote in the article, "resource views" are a specific flavor of
> > "resource variants" and resource variants are explicitly written in the
> > HTTP RFC so I'm sure others implemented ways to have "resource variants"
> > in their web technologies.
> >
> > But I think there is no web technology out there that provides the
> > concept of "resource view" as I designed it: a projection of a
> > multi-dimensional resource onto the requested hyperplane.
> >
> > The "resource variant" concept doesn't take into account
> > multi-dimensional separation of concerns nor considers the resource
> > multi-dimensional.
> >
> > It's a very different thing, even if I agree that all resource views are
> > resource variants.
>
> OK, I think I can just about parse what you're trying to say there, even
> though most of it doesn't make a huge amount of sense to me. It seems to
> me to be saying that you have a way of configuring the same URI to produce
> different content by different means (and different modules), using
> different methods of detecting exactly what to produce (content
> negotiation). I don't see this as something Cocoon can really claim to
> have invented per-se. You could do the same stuff in AxKit too, and I
> don't follow Cocoon development (I pretty much just check in on [RT]
> stuff), so I'm certain other people must have thought of this too.
>
> But I don't want to argue it - its about time we started developing
> technologies around these nearly 3+ year old specs!
:)
> > > Oh, and you should say 6 years, not 10, for when companies ignored the
> > > web. Companies didn't even have the possibility of using the web 10 years
> > > ago (its almost shocking to think it was all that recent...).
> >
> > Why not? it was there. The first implementation dates 1989.
>
> It started off just being in Universities (anyone remember regularly
> checking wuarchive for new uploads?), back when there was more content on
> gopher. In October 1993 there were 200 known HTTP servers (cf
> http://www.w3.org/History.html). 1994 is when it really took off, IIRC. So
> I think 6 years is about right. Your history of the web may vary :-)
Oh, well, I saw my first web page in 1995 so my web history is different
from what you thought... but my point is this: in 1990 there were just
a few sites that hosted an HTTP server. In 2000 there are just a few
sites that host an XML publishing framework.
This is where I see the parallel: Cocoon and friends are now what the
web was 10 years ago, only with much more hype attached due to the XML
label.
It will take another 4 years for XML to really take off and create the
critical mass to starting having semantic searching.
This is my estimation, but I might be wrong: honestly, I don't care if
it's 6 or 10 years, just that XML is hype and we must remove that to be
successful.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [RT] Cocoon Emotional Landscapes
Posted by Mark Washeim <31...@t-online.de>.
on 10/12/00 4:40 PM, Matt Sergeant at matt@sergeant.org wrote:
>>> Oh, and you should say 6 years, not 10, for when companies ignored the
>>> web. Companies didn't even have the possibility of using the web 10 years
>>> ago (its almost shocking to think it was all that recent...).
>>
>> Why not? it was there. The first implementation dates 1989.
>
> It started off just being in Universities (anyone remember regularly
> checking wuarchive for new uploads?), back when there was more content on
> gopher. In October 1993 there were 200 known HTTP servers (cf
> http://www.w3.org/History.html). 1994 is when it really took off, IIRC. So
> I think 6 years is about right. Your history of the web may vary :-)
I concur with matt. I helped start an early Canadian ISP in 94. The telcos,
who quickly gobbled up much of the ISP pie didn't even grok what was up,
until a year later.
When Canada Connect Corporation (canuck.com) started, there where 4 small
companies operating in Alberta. None of them had more than a few hundred
users. The oldest among them was the largest bbs in the region.
There is no question that, until about 95, the vast majority of users where
scientists and pornographers :)
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: [RT] Cocoon Emotional Landscapes
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 12 Oct 2000, Stefano Mazzocchi wrote:
> Matt Sergeant wrote:
> >
> > > - the XSP language (eXtensible Server Pages)
> > > - the sitemap concept
> > > - the resource view concept
> >
> > My only gripe would be that Cocoon somehow invented these
> > concepts. DataChannel invented XSP, the sitemap "concept" is built into
> > Apache (via <Location> tags and options between those tags)
>
> The "cocoon sitemap" concept is that you compose the pipelines using
> modules.
>
> For sure it takes from the Apache sitemap, but Apache sitemaps are based
> on URI matching only, don't have module chaining, don't have the notion
> of views, don't have a bunch of other things.
All of that is, I think, fairly debatable. Handlers can be chained
(although filtering isn't built in, but you can store in the notes table
to emulate filtering in Apache 1.x). And sure it could support views. It
depends what your module does, and how it interprets configuration options
you supply. If you like I can translate your example sitemap to an AxKit
equivalent to show how this can work with Apache 1.x's current config
system.
> And they are not compiled but interpreted.
Dubious. httpd.conf is read at startup time, and values sent to the
respective modules, and the values stored in an apache table
structure. htaccess files are slightly different, of course.
> There is huge difference between Cocoon sitemaps and Apache conf file.
Like I said though, innovation, not invention.
> > and resource
> > views are certainly available in other application servers (before Cocoon
> > ever existed), MediaSurface comes to mind. Innovative, not inventive,
> > IMHO.
>
> Like I wrote in the article, "resource views" are a specific flavor of
> "resource variants" and resource variants are explicitly written in the
> HTTP RFC so I'm sure others implemented ways to have "resource variants"
> in their web technologies.
>
> But I think there is no web technology out there that provides the
> concept of "resource view" as I designed it: a projection of a
> multi-dimensional resource onto the requested hyperplane.
>
> The "resource variant" concept doesn't take into account
> multi-dimensional separation of concerns nor considers the resource
> multi-dimensional.
>
> It's a very different thing, even if I agree that all resource views are
> resource variants.
OK, I think I can just about parse what you're trying to say there, even
though most of it doesn't make a huge amount of sense to me. It seems to
me to be saying that you have a way of configuring the same URI to produce
different content by different means (and different modules), using
different methods of detecting exactly what to produce (content
negotiation). I don't see this as something Cocoon can really claim to
have invented per-se. You could do the same stuff in AxKit too, and I
don't follow Cocoon development (I pretty much just check in on [RT]
stuff), so I'm certain other people must have thought of this too.
But I don't want to argue it - its about time we started developing
technologies around these nearly 3+ year old specs!
> > Oh, and you should say 6 years, not 10, for when companies ignored the
> > web. Companies didn't even have the possibility of using the web 10 years
> > ago (its almost shocking to think it was all that recent...).
>
> Why not? it was there. The first implementation dates 1989.
It started off just being in Universities (anyone remember regularly
checking wuarchive for new uploads?), back when there was more content on
gopher. In October 1993 there were 200 known HTTP servers (cf
http://www.w3.org/History.html). 1994 is when it really took off, IIRC. So
I think 6 years is about right. Your history of the web may vary :-)
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: [RT] Cocoon Emotional Landscapes
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> > - the XSP language (eXtensible Server Pages)
> > - the sitemap concept
> > - the resource view concept
>
> My only gripe would be that Cocoon somehow invented these
> concepts. DataChannel invented XSP, the sitemap "concept" is built into
> Apache (via <Location> tags and options between those tags)
The "cocoon sitemap" concept is that you compose the pipelines using
modules.
For sure it takes from the Apache sitemap, but Apache sitemaps are based
on URI matching only, don't have module chaining, don't have the notion
of views, don't have a bunch of other things.
And they are not compiled but interpreted.
There is huge difference between Cocoon sitemaps and Apache conf file.
> and resource
> views are certainly available in other application servers (before Cocoon
> ever existed), MediaSurface comes to mind. Innovative, not inventive,
> IMHO.
Like I wrote in the article, "resource views" are a specific flavor of
"resource variants" and resource variants are explicitly written in the
HTTP RFC so I'm sure others implemented ways to have "resource variants"
in their web technologies.
But I think there is no web technology out there that provides the
concept of "resource view" as I designed it: a projection of a
multi-dimensional resource onto the requested hyperplane.
The "resource variant" concept doesn't take into account
multi-dimensional separation of concerns nor considers the resource
multi-dimensional.
It's a very different thing, even if I agree that all resource views are
resource variants.
It would be like saying that JPython and Java are the same thing because
both can be compiled in JVM bytecode.
> Oh, and you should say 6 years, not 10, for when companies ignored the
> web. Companies didn't even have the possibility of using the web 10 years
> ago (its almost shocking to think it was all that recent...).
Why not? it was there. The first implementation dates 1989.
> Otherwise it was a good piece with some well presented ideas, so please
> don't take what I've said as a flame - just trying to provide some
> external critique.
No problem. Costructive critique is very welcome :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [RT] Cocoon Emotional Landscapes
Posted by Matt Sergeant <ma...@sergeant.org>.
> - the XSP language (eXtensible Server Pages)
> - the sitemap concept
> - the resource view concept
My only gripe would be that Cocoon somehow invented these
concepts. DataChannel invented XSP, the sitemap "concept" is built into
Apache (via <Location> tags and options between those tags), and resource
views are certainly available in other application servers (before Cocoon
ever existed), MediaSurface comes to mind. Innovative, not inventive,
IMHO.
Oh, and you should say 6 years, not 10, for when companies ignored the
web. Companies didn't even have the possibility of using the web 10 years
ago (its almost shocking to think it was all that recent...).
Otherwise it was a good piece with some well presented ideas, so please
don't take what I've said as a flame - just trying to provide some
external critique.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\