You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2003/01/07 22:50:14 UTC
site and book documents
Hi,
I have had a look at creating books or collections of documents. The idea is to be able to create
book.pdf's and a site.pdf.
This is just an attempt to look at the problem.
The normal tabs.xml and book.xml seem to have the wrong information for this.
I couldn't find a good way to handle it through the book.xml. For a few reasons:
- it may contain external or other different url's
- it would need to do some processing to get the actual xml input
- it could be self referencing
Instead I thought that it could work with different files with the same format.
Instead ref-tabs.xml and ref-book.xml are used to refer to the xml files to be included. A stylesheet
can then convert the ref-tabs.xml into a document containing all the referenced xml documents, the
combined document can then be converted as normal.
Problems:
- it gets an error due to not finding the dtd files, some resolver problem
- documents in other directories can be included so that relative links will be wrong
- if it refers to a generated xml (eg. todo.xml) then it cannot load the xml
- the url does not relate to the resource
- it means there are two books that need maintaining
There are probably better names for the parts.
Can anyone see a better way of doing this?
Anyway I think this sort of things should be considered.
I have attached a sample of how it could be done. With an example in the fresh site.
Keiron
Re: site and book documents
Posted by Jeff Turner <je...@apache.org>.
On Wed, Jan 08, 2003 at 11:22:38AM +0100, Marc Portier wrote:
...
> >>>This isn't a full solution though, because formats other than doc-v11
> >>>won't be integrated. That would be easy with a <map:aggregate>, but
> >>>I'm not sure how to aggregate dynamically.
> >>>
> >>interesting thought... maybe the merging should be defined on the
> >>intermediate (pre-skin format)
> >
> >Yes.
> >
> think xinclude would pick-in at the src level?
> while something more <xdoc:include> would do on the intermediate?
I *think* Cocoon's XInclude transformer can use arbitrary Sources, so we
could aggregate either sources or intermediate formats:
<body>
<xi:include href="cocoon:body-index.xml#xpointer(/document/body/*)"/>
<xi:include href="cocoon:body-primer.xml#xpointer(/document/body/*)"/>
<xi:include href="cocoon:body-faq.xml#xpointer(/document/body/*)"/>
<xi:include href="cocoon:body-changes.xml#xpointer(/document/body/*)"/>
</body>
--Jeff
Re: site and book documents
Posted by Marc Portier <mp...@outerthought.org>.
Jeff Turner wrote:
> On Wed, Jan 08, 2003 at 09:40:41AM +0100, Marc Portier wrote:
<snip/>
Jeff, isn't your question...
>>personally I was thinking about this more along the lines of
>>having a <inline-link href="site:some_part" /> inside xdoc
>>format itself.
>
>
> XInclude then?
>
answered here at the bottom?
>>>This isn't a full solution though, because formats other than doc-v11
>>>won't be integrated. That would be easy with a <map:aggregate>, but
>>>I'm not sure how to aggregate dynamically.
>>>
>>
>>interesting thought... maybe the merging should be defined on the
>>intermediate (pre-skin format)
>
>
> Yes.
>
think xinclude would pick-in at the src level?
while something more <xdoc:include> would do on the intermediate?
> --Jeff
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: site and book documents
Posted by Jeff Turner <je...@apache.org>.
On Wed, Jan 08, 2003 at 09:40:41AM +0100, Marc Portier wrote:
>
>
> Jeff Turner wrote:
> >On Wed, Jan 08, 2003 at 07:50:14AM +1000, Keiron Liddle wrote:
>
> <snip/>
>
> >>
> >>Instead I thought that it could work with different files with the same
> >>format. Instead ref-tabs.xml and ref-book.xml are used to refer to the
> >>xml files to be included. A stylesheet can then convert the
> >>ref-tabs.xml into a document containing all the referenced xml
> >>documents, the combined document can then be converted as normal.
> >
> >
> >That does seem better.
> >
>
> personally I was thinking about this more along the lines of
> having a <inline-link href="site:some_part" /> inside xdoc
> format itself.
XInclude then?
> this would also allow for sort of binding-text (that has no
> meaning by itself)
>
> then we could have a transformer that pics up these 'inlines' and
> produces the full document to be processed further down the line
> 'as normal'. Persumably it would only inline the <body>
> element... not fully sure whether we should have some xpath
> fragment identifier inside the link to include (is feasible but
> kinda breaks the SAX processing I think)
>
> I guess the next thing would be to allow for link-backs, so when
> you have the html version of some-part alone it could show links
> of larger agregated documents that embody it (this starts to
> sound like xlink, uh)
>
...
> >This is implemented with the XPathDirectoryGenerator in Cocoon scratchpad.
> >
> > <!-- Support for merged views of a directory's contents -->
> > <map:match pattern="body-book.xml">
> > <map:generate type="xpathdirectory"
> > src="content/xdocs#/document/*"/>
> > <map:transform src="resources/stylesheets/directory2document.xsl"/>
> > <map:call resource="skinit">
> > <map:parameter name="type" value="document2html"/>
> > <map:parameter name="path" value="book"/>
> > </map:call>
> > </map:match>
>
> Nice. Stuff like this could reside in the forrest cvs as well,
> no? Next to having the forrest-seed-fresh-site we should maybe
> have a samples section as well?
It's really just a custom sitemap and stylesheet added to a 'seed' site.
If this were in CVS, we'd need to basically duplicate the seed files for
every 'sample'. Keeping samples on a webserver somewhere would be
better..
Actually, I've been thinking how we could use Forrest to make Cocoon
development easier. By adding a build.xml to the seed site, we have an
ideal environment for quickly developing components like Transformers.
The Java code, XML documentation and sitemap example are all contained in
one small package.
> >This isn't a full solution though, because formats other than doc-v11
> >won't be integrated. That would be easy with a <map:aggregate>, but
> >I'm not sure how to aggregate dynamically.
> >
>
> interesting thought... maybe the merging should be defined on the
> intermediate (pre-skin format)
Yes.
--Jeff
Re: site and book documents
Posted by Marc Portier <mp...@outerthought.org>.
Jeff Turner wrote:
> On Wed, Jan 08, 2003 at 07:50:14AM +1000, Keiron Liddle wrote:
<snip/>
>>
>>Instead I thought that it could work with different files with the same
>>format. Instead ref-tabs.xml and ref-book.xml are used to refer to the
>>xml files to be included. A stylesheet can then convert the
>>ref-tabs.xml into a document containing all the referenced xml
>>documents, the combined document can then be converted as normal.
>
>
> That does seem better.
>
personally I was thinking about this more along the lines of
having a <inline-link href="site:some_part" /> inside xdoc
format itself.
this would also allow for sort of binding-text (that has no
meaning by itself)
then we could have a transformer that pics up these 'inlines' and
produces the full document to be processed further down the line
'as normal'. Persumably it would only inline the <body>
element... not fully sure whether we should have some xpath
fragment identifier inside the link to include (is feasible but
kinda breaks the SAX processing I think)
I guess the next thing would be to allow for link-backs, so when
you have the html version of some-part alone it could show links
of larger agregated documents that embody it (this starts to
sound like xlink, uh)
>
> I think it would be better to let the sitemap do all the XML merging,
> transforming etc.
>
> At:
>
> http://cvs.apache.org/~jefft/forrest/samples/merge.tgz
>
> there is a sample project with a 'BookView' menu entry, which has a HTML
> and PDF containing all merged content in the directory. Generated PDF at:
>
> http://cvs.apache.org/~jefft/forrest/samples/book.pdf
>
> This is implemented with the XPathDirectoryGenerator in Cocoon scratchpad.
>
> <!-- Support for merged views of a directory's contents -->
> <map:match pattern="body-book.xml">
> <map:generate type="xpathdirectory"
> src="content/xdocs#/document/*"/>
> <map:transform src="resources/stylesheets/directory2document.xsl"/>
> <map:call resource="skinit">
> <map:parameter name="type" value="document2html"/>
> <map:parameter name="path" value="book"/>
> </map:call>
> </map:match>
Nice. Stuff like this could reside in the forrest cvs as well,
no? Next to having the forrest-seed-fresh-site we should maybe
have a samples section as well?
>
> This isn't a full solution though, because formats other than doc-v11 won't be
> integrated. That would be easy with a <map:aggregate>, but I'm not sure how to
> aggregate dynamically.
>
interesting thought... maybe the merging should be defined on the
intermediate (pre-skin format)
>
> --Jeff
>
>
>>Anyway I think this sort of things should be considered.
>>
>>I have attached a sample of how it could be done. With an example in the fresh site.
>>
>>Keiron
>>
>>
>
>
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: site and book documents
Posted by Jeff Turner <je...@apache.org>.
On Wed, Jan 08, 2003 at 07:50:14AM +1000, Keiron Liddle wrote:
> Hi,
>
> I have had a look at creating books or collections of documents. The
> idea is to be able to create book.pdf's and a site.pdf.
Just to clarify.. site.pdf contains content for the whole site? And
book.pdf for the whole subdir?
> This is just an attempt to look at the problem.
>
> The normal tabs.xml and book.xml seem to have the wrong information for this.
>
> I couldn't find a good way to handle it through the book.xml. For a few reasons:
> - it may contain external or other different url's
> - it would need to do some processing to get the actual xml input
> - it could be self referencing
>
> Instead I thought that it could work with different files with the same
> format. Instead ref-tabs.xml and ref-book.xml are used to refer to the
> xml files to be included. A stylesheet can then convert the
> ref-tabs.xml into a document containing all the referenced xml
> documents, the combined document can then be converted as normal.
That does seem better.
> Problems:
> - it gets an error due to not finding the dtd files, some resolver problem
I noticed that too when trying to use document('book.xml'). It looks
like the XSLT engine hasn't been told by Cocoon to use the catalog
EntityResolver.
> - documents in other directories can be included so that relative links will be wrong
> - if it refers to a generated xml (eg. todo.xml) then it cannot load the xml
> - the url does not relate to the resource
> - it means there are two books that need maintaining
>
> There are probably better names for the parts.
> Can anyone see a better way of doing this?
I think it would be better to let the sitemap do all the XML merging,
transforming etc.
At:
http://cvs.apache.org/~jefft/forrest/samples/merge.tgz
there is a sample project with a 'BookView' menu entry, which has a HTML
and PDF containing all merged content in the directory. Generated PDF at:
http://cvs.apache.org/~jefft/forrest/samples/book.pdf
This is implemented with the XPathDirectoryGenerator in Cocoon scratchpad.
<!-- Support for merged views of a directory's contents -->
<map:match pattern="body-book.xml">
<map:generate type="xpathdirectory"
src="content/xdocs#/document/*"/>
<map:transform src="resources/stylesheets/directory2document.xsl"/>
<map:call resource="skinit">
<map:parameter name="type" value="document2html"/>
<map:parameter name="path" value="book"/>
</map:call>
</map:match>
This isn't a full solution though, because formats other than doc-v11 won't be
integrated. That would be easy with a <map:aggregate>, but I'm not sure how to
aggregate dynamically.
--Jeff
> Anyway I think this sort of things should be considered.
>
> I have attached a sample of how it could be done. With an example in the fresh site.
>
> Keiron
>
>