You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Paulo Gaspar <pa...@krankikom.de> on 2000/10/16 02:29:27 UTC
RE: [RT] Cocoon Emotional Landscapes - semantic searching
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 - 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...