You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Bernhard Huber <be...@a1.net> on 2002/12/15 03:12:27 UTC
[RT] LinkTranslator Usage (Sitemap woes and semantic linking)
hi,
i was following the discussion about Cocoon CLI, and about links
now i checked the sources of LinkTranslator and its usage
inside of Cocoon.
I was having a problem about serving content as html, and as
wml.
Generating wml, or html content from an xml document was
no real problem thanks to sitemap, xslt.
But linking of the document was not that obvious.
Originally i was using inside of the documents
<link href="index.html">, but as i was implementing the wml
stuff i releaized that i once should have
<link href="index.html">, and <link href="index.wml"> for the
wml stuff, as link/@href was transformed in the xslt stylesheets
site2html.xsl, or site2wml.xsl.
Inspired by the schema/protocol discussiion i now
use <link href="page:index"/>.
An action named "link-map-translator" sets the Constants.LINK_OBJECT
table of the objectModel to a table which returns
for an href "page:index" index.html, or index.wml depending
on the extension of the Action src extension values.
The contract i was implementing:
A browser requests index.html, hrefs of the form page:XXX
are translated due to the requested page extension '.html'
to XXX.html, ditto for index.wml is translated to XXX.wml.
This way i write now xml documents which can be published
for html, or wml
I was not aware of the possibilities of LinkTranslator,
although it is used in CocoonCLI/FileSavingEnvironment.
hope it helps in understanding Cocoon "hidden" features a
bit better.
bye bernhard
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator
Usage)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
[...]
> Yep :) Manage a whole site's linking from a few metadata files and a linkmap.
The description of the link system is basically in line with my opinions
too, so I'm +1 for it.
This BTW, addresses Concern 1 of
http://marc.theaimsgroup.com/?l=forrest-dev&m=103976582923758&w=2
What we will need after this, to be able to complete the picture, is a
resourcemap, that maps resources to real sources.
The linkmap makes us manage a whole site's linking, ie the resulting URIs.
The resourcemap will make us manage the whole source space, so that we
will be able to change the way sources are gotten without touching the
sitemap. For example, I could pass from a file system to a db without
touching the sitemap.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 10:08:49AM +0100, Bernhard Huber wrote:
> hi,
>
> >
> > With link translation, we need exactly the same thing! Given a semantic
> > link, we need to look up a 'real' link. In particular, to implement a
> > linkmap, we need exactly XMLFileModule's functionality. A link like
> > <link href="site:/primer">, the address 'site:/primer' can be resolved by
> > looking up a 'site' input module (mapped to an XMLFileModule), which
> > would then use '/primer' as an XPath expression to look up the node.
> >
> okay, you have a "<link href="site:/primer"> in you xml-document.
> The LinkTranslator/LinkRewriterTransformer can rewrite/map site:/primer
> to some new href.
>
> okay, the details of rewrite/map are either implemented by
> LinkTranslator or LinkRewriterTransformer.
>
> As LinkTranslator is implemented now Cocoon2.1 as far as i understand
> can only rewrite the link. Thus the above "<link href="site:/primer>"
> may rewritten to "<link href="primer.html">.
Yes, that's the basic idea. Btw, a 'linkmap' is an XML mapping from 'semantic'
URIs ike 'page:/index' to physical sources (index.xml) and final destination
(index.wml or index.html):
http://marc.theaimsgroup.com/?t=103444042500002&r=1&w=2
> > So anyway, I'm thinking, how about implementing this as a generic
> > InputModuleTransformer, which is configured with a) an InputModule, b) an
> > XPath expression of nodes to transform. So to transform hrefs in links,
> > we'd have:
> >
> > <map:transformers>
> > <map:transformer name="inputmodule"
> src="o.a.c.t.InputModuleTransformer">
> > <input-module>linkmap</input-module>
> > ...
> > <transformed-nodes>//link/@href</transformed-nodes>
> > </map:transformer>
> > </map:transformers>
> >
> > Where 'linkmap' is defined in cocoon.xconf as:
> >
> > <component-instance name="linkmap"
> class="o.a.c.c.modules.input.XMLFileModule"
> > <file src="context://linkmap.xml"/>
> > </component-instance>
> >
> > Since XMLFileModule can use any Source, so can our linking system. Want
> > to link to whatever's the top Slashdot article? Add a 'slashdot'
> > InputModule (in the samples sitemap), and add <link
> > href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
> > XML.
> >
> > What do people think? Is this the base for a majorly cool linking
> > system, or am I missing something?
> >
> I must admit that i have followed a bit the module-discussion,
> but don't know how-to use it in the sitemap.
Just {module:key} variables. See src/webapp/samples/modules/sitemap.xmap.
> The LinkRewriterTransformer seems to be a bit more flexible.
> What is the rewritten <link href="slashdot:/*:RDF/item[1]/title">?
> Does linkmap.xml contains the mapping?
No, the transformer would lookup up InputModule called 'slashdot', which
is defined as follows in cocoon.xconf:
<component-instance name="slashdot" class="o.a.c.c.modules.input.XMLFileModule">
<file src="http://slashdot.org/slashdot.rss"/>
</component-instance>
So '/*:RDF/item[1]/title' is an XPath address for a node in slashdot.rss.
Actually that returns the title; we'd want /*:RDF/item[1]/link, which currently
is returning:
<link>http://slashdot.org/article.pl?sid=02/12/15/0247238</link>
> The cool feature of a linking system:
> Slashdot changes its internal linking, only updating the linkmap.xml
> will adopt my site to the new slashdot structure w/o changing the xml
> documents
> of my site.
> As far as i see LinkTranslator/LinkTransformer support this.
Yep :) Manage a whole site's linking from a few metadata files and a linkmap.
I am currently re-jigging my XPathTransformer to create all this.
--Jeff
> bye bernhard
>
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator
Usage)
Posted by Bernhard Huber <be...@a1.net>.
hi,
>
> With link translation, we need exactly the same thing! Given a semantic
> link, we need to look up a 'real' link. In particular, to implement a
> linkmap, we need exactly XMLFileModule's functionality. A link like
> <link href="site:/primer">, the address 'site:/primer' can be resolved by
> looking up a 'site' input module (mapped to an XMLFileModule), which
> would then use '/primer' as an XPath expression to look up the node.
>
okay, you have a "<link href="site:/primer"> in you xml-document.
The LinkTranslator/LinkRewriterTransformer can rewrite/map site:/primer
to some new href.
okay, the details of rewrite/map are either implemented by
LinkTranslator or LinkRewriterTransformer.
As LinkTranslator is implemented now Cocoon2.1 as far as i understand
can only rewrite the link. Thus the above "<link href="site:/primer>"
may rewritten to "<link href="primer.html">.
>
> So anyway, I'm thinking, how about implementing this as a generic
> InputModuleTransformer, which is configured with a) an InputModule, b) an
> XPath expression of nodes to transform. So to transform hrefs in links,
> we'd have:
>
> <map:transformers>
> <map:transformer name="inputmodule"
src="o.a.c.t.InputModuleTransformer">
> <input-module>linkmap</input-module>
> ...
> <transformed-nodes>//link/@href</transformed-nodes>
> </map:transformer>
> </map:transformers>
>
> Where 'linkmap' is defined in cocoon.xconf as:
>
> <component-instance name="linkmap"
class="o.a.c.c.modules.input.XMLFileModule"
> <file src="context://linkmap.xml"/>
> </component-instance>
>
> Since XMLFileModule can use any Source, so can our linking system. Want
> to link to whatever's the top Slashdot article? Add a 'slashdot'
> InputModule (in the samples sitemap), and add <link
> href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
> XML.
>
> What do people think? Is this the base for a majorly cool linking
> system, or am I missing something?
>
I must admit that i have followed a bit the module-discussion,
but don't know how-to use it in the sitemap.
The LinkRewriterTransformer seems to be a bit more flexible.
What is the rewritten <link href="slashdot:/*:RDF/item[1]/title">?
Does linkmap.xml contains the mapping?
The cool feature of a linking system:
Slashdot changes its internal linking, only updating the linkmap.xml
will adopt my site to the new slashdot structure w/o changing the xml
documents
of my site.
As far as i see LinkTranslator/LinkTransformer support this.
bye bernhard
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Dec 16, 2002 at 09:51:55AM +0100, Christian Haul wrote:
> On 15.Dec.2002 -- 03:36 PM, Jeff Turner wrote:
> > So anyway, I'm thinking, how about implementing this as a generic
> > InputModuleTransformer, which is configured with a) an InputModule, b) an
> > XPath expression of nodes to transform. So to transform hrefs in links,
> > we'd have:
> >
> > <map:transformers>
> > <map:transformer name="inputmodule" src="o.a.c.t.InputModuleTransformer">
> > <input-module>linkmap</input-module>
> > ...
> > <transformed-nodes>//link/@href</transformed-nodes>
> > </map:transformer>
> > </map:transformers>
> >
> > Where 'linkmap' is defined in cocoon.xconf as:
> >
> > <component-instance name="linkmap" class="o.a.c.c.modules.input.XMLFileModule"
> > <file src="context://linkmap.xml"/>
> > </component-instance>
> >
> > Since XMLFileModule can use any Source, so can our linking system. Want
> > to link to whatever's the top Slashdot article? Add a 'slashdot'
> > InputModule (in the samples sitemap), and add <link
> > href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
> > XML.
> >
> > What do people think? Is this the base for a majorly cool linking
> > system, or am I missing something?
>
> Jeff,
> I think this is a great idea! Some ideas:
>
> *) It might be nice to use the syntax from sitemap, i.e. the
> transformer would not be bound to a single module but dynamically
> look them up "{linkmap:something}"
Yes, I'm currently cut-pasting sections from *MetaModule.java to support
this.
> I guess the "..." above indicate that more than one module may be
> used but I wonder what it buys to have their declaration locally to
> the transformer.
I guess there isn't much reason to explicitly list the available input
modules. I was copying ChainMetaModule.
> Granted, this way you can deviate from the global configuration of a
> module. Maybe the transformer could use all modules and use a
> special configuration for those listed in the configuration section?
I don't understand.. what configuration section? Why would a Transformer
try to configure InputModules? Can't the transformer just say
inputSelector.select("blah") and rely on the cocoon.xconf configuration
of the 'blah' InputModule?
> For the input.xsl logicsheet I have created a simple helper class
> that handles a list of modules during execution. Perhaps this class
> could be used by the transformer (would need some additions for the
> configurations):
> o.a.c.components.language.markup.xsp.XSPModuleHelper.java
Thanks, that is very helpful. I'm way out of my depth with this stuff.
> *) limiting the transformer to nodes matching an XPath expression is
> cool. But it might be expensive: It might require the transformer
> to keep / build a DOM representation of the document so that the
> XPathProcessor can be used.
Yes, so I discovered. It is very hard to divide a DOM into two sets of nodes,
those selected by XPath and those not.
> Alternatives could be to act on every attribute (expensive), act on
> every attribute of elements belonging to the target namespace, dito
> but only certain attributes or specific elements. Those could be
> decided without knowledge of the rest of the document but appear
> not to restrict the application too much.
Currently I'm checking a configurable list of attributes (eg href, src)
for ':', and processing those. So <link href="site:/primer"> would
trigger inputSelector.select("site"), and then
module.getAttribute("/primer", ...). I haven't figured out the '...'
part yet:)
--Jeff
PS: There is a bug in ChainMetaModule, caused by too few brackets. The 'else'
is associating with the wrong 'if':
public void dispose() {
if (!this.initialized.booleanValue())
if (getLogger().isErrorEnabled())
getLogger().error("Uninitialized Component! dispose() FAILING");
else
if (this.inputSelector != null) {
for (int i=0; i<this.inputs.length; i++) {
if (this.inputs[i].input != null)
this.inputSelector.release(this.inputs[i].input);
}
this.manager.release(this.inputSelector);
}
}
> Cheers,
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 15.Dec.2002 -- 03:36 PM, Jeff Turner wrote:
> So anyway, I'm thinking, how about implementing this as a generic
> InputModuleTransformer, which is configured with a) an InputModule, b) an
> XPath expression of nodes to transform. So to transform hrefs in links,
> we'd have:
>
> <map:transformers>
> <map:transformer name="inputmodule" src="o.a.c.t.InputModuleTransformer">
> <input-module>linkmap</input-module>
> ...
> <transformed-nodes>//link/@href</transformed-nodes>
> </map:transformer>
> </map:transformers>
>
> Where 'linkmap' is defined in cocoon.xconf as:
>
> <component-instance name="linkmap" class="o.a.c.c.modules.input.XMLFileModule"
> <file src="context://linkmap.xml"/>
> </component-instance>
>
> Since XMLFileModule can use any Source, so can our linking system. Want
> to link to whatever's the top Slashdot article? Add a 'slashdot'
> InputModule (in the samples sitemap), and add <link
> href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
> XML.
>
> What do people think? Is this the base for a majorly cool linking
> system, or am I missing something?
Jeff,
I think this is a great idea! Some ideas:
*) It might be nice to use the syntax from sitemap, i.e. the
transformer would not be bound to a single module but dynamically
look them up "{linkmap:something}"
I guess the "..." above indicate that more than one module may be
used but I wonder what it buys to have their declaration locally to
the transformer. Granted, this way you can deviate from the global
configuration of a module.
Maybe the transformer could use all modules and use a special
configuration for those listed in the configuration section?
For the input.xsl logicsheet I have created a simple helper class
that handles a list of modules during execution. Perhaps this class
could be used by the transformer (would need some additions for the
configurations):
o.a.c.components.language.markup.xsp.XSPModuleHelper.java
*) limiting the transformer to nodes matching an XPath expression is
cool. But it might be expensive: It might require the transformer
to keep / build a DOM representation of the document so that the
XPathProcessor can be used.
Alternatives could be to act on every attribute (expensive), act on
every attribute of elements belonging to the target namespace, dito
but only certain attributes or specific elements. Those could be
decided without knowledge of the rest of the document but appear
not to restrict the application too much.
Cheers,
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator
Usage)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
[...]
> So anyway, I'm thinking, how about implementing this as a generic
> InputModuleTransformer, which is configured with a) an InputModule, b) an
> XPath expression of nodes to transform.
[...]
> Since XMLFileModule can use any Source, so can our linking system. Want
> to link to whatever's the top Slashdot article? Add a 'slashdot'
> InputModule (in the samples sitemap), and add <link
> href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
> XML.
>
> What do people think? Is this the base for a majorly cool linking
> system, or am I missing something?
I'm totally with you here; I've been using also jxpath in centipede with
enourmous satisfaction.
+1 all the way, this is not FS IMO, it rocks! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
[RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 03:12:27AM +0100, Bernhard Huber wrote:
> hi,
>
> i was following the discussion about Cocoon CLI, and about links
> now i checked the sources of LinkTranslator and its usage
> inside of Cocoon.
>
> I was having a problem about serving content as html, and as
> wml.
> Generating wml, or html content from an xml document was
> no real problem thanks to sitemap, xslt.
> But linking of the document was not that obvious.
>
> Originally i was using inside of the documents
> <link href="index.html">, but as i was implementing the wml
> stuff i releaized that i once should have
> <link href="index.html">, and <link href="index.wml"> for the
> wml stuff, as link/@href was transformed in the xslt stylesheets
> site2html.xsl, or site2wml.xsl.
>
> Inspired by the schema/protocol discussiion i now
> use <link href="page:index"/>.
>
> An action named "link-map-translator" sets the Constants.LINK_OBJECT
> table of the objectModel to a table which returns
> for an href "page:index" index.html, or index.wml depending
> on the extension of the Action src extension values.
Nice :) I wasn't aware of LinkTranslator, and am just getting started on
a LinkRewriterTransformer, so yours is a very timely email. I'll have a
go at wrapping the XLink machinery in o.a.c.xml.xlink in a Transformer.
Here's a thought..
Christian Haul, Konstantin and others have created a very cool Input
Module system. The input module API is roughly a Map: give it a key, and
out comes a value. For example, using the XMLFileModule, one can
retrieve the value of an XML node with:
<map:parameter name="skin" value="{myxml:/forrestconf/skin}"/>
With link translation, we need exactly the same thing! Given a semantic
link, we need to look up a 'real' link. In particular, to implement a
linkmap, we need exactly XMLFileModule's functionality. A link like
<link href="site:/primer">, the address 'site:/primer' can be resolved by
looking up a 'site' input module (mapped to an XMLFileModule), which
would then use '/primer' as an XPath expression to look up the node.
Because we have JXPath underlying many InputModules, we now have a _very_
powerful link resolution system. For example, say we want to implement
an 'info:' scheme for accessing Gump-based project data. In the short
term, we can fish the info out of module.xml directly using
XMLFileModule. Then one day when Nicola et al finish ViProM [1], we can
switch to that, with almost no code changes.
At this point, I'd expect many Cocooners to be shouting "FS! We don't
need all of InputModule's power in links. It will overheat users' brains!
Think of the children!". Well, I personally don't think this is FS at
all: we make simple things easy, hard things possible, all by _reusing_
existing code. But perhaps I don't have the right notion of what FS is.
So anyway, I'm thinking, how about implementing this as a generic
InputModuleTransformer, which is configured with a) an InputModule, b) an
XPath expression of nodes to transform. So to transform hrefs in links,
we'd have:
<map:transformers>
<map:transformer name="inputmodule" src="o.a.c.t.InputModuleTransformer">
<input-module>linkmap</input-module>
...
<transformed-nodes>//link/@href</transformed-nodes>
</map:transformer>
</map:transformers>
Where 'linkmap' is defined in cocoon.xconf as:
<component-instance name="linkmap" class="o.a.c.c.modules.input.XMLFileModule"
<file src="context://linkmap.xml"/>
</component-instance>
Since XMLFileModule can use any Source, so can our linking system. Want
to link to whatever's the top Slashdot article? Add a 'slashdot'
InputModule (in the samples sitemap), and add <link
href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your
XML.
What do people think? Is this the base for a majorly cool linking
system, or am I missing something?
--Jeff
[1] http://krysalis.org/cgi-bin/krywiki.pl?ViProM
>
> bye bernhard
>
Re: [RT] LinkTranslator Usage (Sitemap woes and semantic linking)
Posted by Bernhard Huber <be...@a1.net>.
hi,
<snip/>
>>Originally i was using inside of the documents
>><link href="index.html">, but as i was implementing the wml
>>stuff i releaized that i once should have
>><link href="index.html">, and <link href="index.wml"> for the
>>wml stuff, as link/@href was transformed in the xslt stylesheets
>>site2html.xsl, or site2wml.xsl.
>
>
> But can you really have this one-to-one relationship? Perhaps the site you are
> building can, but the reality I deal with would not allow this type of thing. In
> my experience the WML site needs a different number of pages(length, navigation,
> linking, etc). For me, this requires a different site structure that can only be
> acheived by laying out the site in a different way. Perhaps I am missing
> something?
>
About one-to-one relationship:
For me it works, moreover one "requirement" of the site design was
reusing xml-document for the html AND for the wml site.
Thus i have xml-document which do not want to change for publishing
under wml, and html.
Of course wml, and html has different site structure, this is handled
in the site2hml.xsl, respectivly in the site2wml.xsl. But that's layout.
And of course you can do the "page:XXXX" --> index.html, respectivly
page:XXXX -> index.wml in the stylsheets or some other transformers,
but i want to do the right thing in the right stage.
Thus layouting is implemented in the xsl, links are channel independent
written in the xml-documents, independent channel links are made
concrete in the LinkTranslator stage.
best regards bernhard
RE: [RT] LinkTranslator Usage (Sitemap woes and semantic linking)
Posted by Robert Koberg <ro...@koberg.com>.
Hi Bernhard
> -----Original Message-----
> From: Bernhard Huber [mailto:berni_huber@a1.net]
> Sent: Saturday, December 14, 2002 6:12 PM
> To: forrest-dev@xml.apache.org
> Subject: [RT] LinkTranslator Usage (Sitemap woes and semantic linking)
>
>
> hi,
>
> i was following the discussion about Cocoon CLI, and about links
> now i checked the sources of LinkTranslator and its usage
> inside of Cocoon.
>
> I was having a problem about serving content as html, and as
> wml.
> Generating wml, or html content from an xml document was
> no real problem thanks to sitemap, xslt.
> But linking of the document was not that obvious.
>
> Originally i was using inside of the documents
> <link href="index.html">, but as i was implementing the wml
> stuff i releaized that i once should have
> <link href="index.html">, and <link href="index.wml"> for the
> wml stuff, as link/@href was transformed in the xslt stylesheets
> site2html.xsl, or site2wml.xsl.
But can you really have this one-to-one relationship? Perhaps the site you are
building can, but the reality I deal with would not allow this type of thing. In
my experience the WML site needs a different number of pages(length, navigation,
linking, etc). For me, this requires a different site structure that can only be
acheived by laying out the site in a different way. Perhaps I am missing
something?
best,
-Rob
>
> Inspired by the schema/protocol discussiion i now
> use <link href="page:index"/>.
>
> An action named "link-map-translator" sets the Constants.LINK_OBJECT
> table of the objectModel to a table which returns
> for an href "page:index" index.html, or index.wml depending
> on the extension of the Action src extension values.
>
> The contract i was implementing:
> A browser requests index.html, hrefs of the form page:XXX
> are translated due to the requested page extension '.html'
> to XXX.html, ditto for index.wml is translated to XXX.wml.
>
> This way i write now xml documents which can be published
> for html, or wml
>
> I was not aware of the possibilities of LinkTranslator,
> although it is used in CocoonCLI/FileSavingEnvironment.
>
> hope it helps in understanding Cocoon "hidden" features a
> bit better.
>
> bye bernhard
>