docbook-apps

L.S.,

I just forked the trunk and created a new branch, where I can work on the website re-implementation.

In the interest of transparency, I had first copied the trunk into /docbook/website5 when it should clearly have been /docbook/branches/website5. Then I svn moved it to where it belonged. Sorry!

$ svn mv https://.../docbook/website5 https://.../docbook/branches/website5

BTW, how can receive checkin notifications? There's [1] but it doesn't seem to post notifications for each commit. I was hoping to receive a notification email for each commit in hopes to gradually merge them with my branch. I'll especially need to keep up with Jirka's commits to the XSLT2 stylesheets.

SinDoc

[1] https://sourceforge.net/mailarchive/forum.php?forum_name=docbook-checkins

On Mon, May 17, 2010 at 5:24 PM, Sina K. Heshmati <sina@khakbaz.com> wrote:
> I just forked the trunk and created a new branch, where I can work on the website re-implementation.

Sounds good.

> BTW, how can receive checkin notifications?

Well, I saw your commit in my feed reader:
http://cia.vc/stats/project/docbook/.message/255fb0
Here is the feed: http://cia.vc/stats/project/docbook/.rss

> I'll especially need to keep up with Jirka's commits to the XSLT2 stylesheets.

Oh, that's under active development again!? How did I miss that?


Keith

Keith Fahlgren wrote:
> Sina K. Heshmati wrote:
>> BTW, how can I receive checkin notifications?
>
> Well, I saw your commit in my feed reader:
> http://cia.vc/stats/project/docbook/.message/255fb0
> Here is the feed: http://cia.vc/stats/project/docbook/.rss

Thanks for sharing, Keith.

If it's not email, let it be aggregated over HTTP. DocBook's update feed from SourceForge can also be used:
https://sourceforge.net/export/rss2_keepsake.php?group_id=21935

>> I'll especially need to keep up with Jirka's commits to the XSLT2 stylesheets.
>
> Oh, that's under active development again!? How did I miss that?

Not yet. I meant to imply sometime in the near future.

SinDoc

Am Dienstag, den 18.05.2010, 02:24 +0200 schrieb Sina K. Heshmati:

> I just forked the trunk and created a new branch, where I can work on
> the website re-implementation.

I guess these were SVN revisions 8621-23? (Because they are missing from
the checkins list.)

[..]
> BTW, how can receive checkin notifications? There's [1] but it doesn't
> seem to post notifications for each commit. I was hoping to receive a
> notification email for each commit in hopes to gradually merge them
> with my branch.

You need to have posting rights to the list. But the listmasters don't
seem to be active. So your mails are not automatically accepted, because
nobody fixes the rules. My commits are also "lost". Maybe the project
admins can fix or take over the list maintainership.

Regards, Daniel

Not sure if this the best place to post this, but here goes:

Sina, I'm so glad to see active development on Website, it's such a
terrific product. As long as you're thinking about its next stage of
development, has anyone suggested folding Website into DocBook? I use
both all the time, and I think each has features that could enhance the
other.

I once implemented a doc set that pulled together a bunch of DocBooks
and some non-DocBook content using an olink sitemap. I was amazed to
learn how powerful sitemaps and generated olink databases are. It
occurred to me that they could be used to do far more than enable
olinks: they contain all the metadata you need to organize and process a
whole doc system -- not unlike Website layouts (and ditamaps, for that
matter). On the company web site we served our doc set as an Eclipse
infocenter, but I couldn't help thinking how much easier it would have
been to post it as a Website.

Another example, on the Website side: why should only books and help
systems have an index? It's a great navigation tool for an informational
web site, too. So, I hacked the Website stylesheets to generate a
DocBook index for the site. Not pretty XSL, but my readers love the index.

I realize this is not a trivial thing. Besides the layout, there doesn't
appear to be much difference between the DocBook and Website (full)
documents -- mostly a few elements at the top. But the big difference is
in the processing, and that would no doubt require a lot of work to bridge.

The benefits just might be worth the effort. Making Website a DocBook
output option, instead of a separate dialect, would increase its value
for technical documentation -- a low-tech, frameless alternative to
Eclipse infocenters and HTML-based help browsers.

Thanks,
Denis

On Thu, 20 May 2010, Denis Bradford wrote:
> Not sure if this the best place to post this, but here goes:
>
> Sina, I'm so glad to see active development on Website, it's such a
> terrific product. As long as you're thinking about its next stage of
> development, has anyone suggested folding Website into DocBook? I use
> both all the time, and I think each has features that could enhance the
> other.
>
> I once implemented a doc set that pulled together a bunch of DocBooks
> and some non-DocBook content using an olink sitemap. I was amazed to
> learn how powerful sitemaps and generated olink databases are. It
> occurred to me that they could be used to do far more than enable
> olinks: they contain all the metadata you need to organize and process a
> whole doc system -- not unlike Website layouts (and ditamaps, for that
> matter). On the company web site we served our doc set as an Eclipse
> infocenter, but I couldn't help thinking how much easier it would have
> been to post it as a Website.
>
> Another example, on the Website side: why should only books and help
> systems have an index? It's a great navigation tool for an informational
> web site, too. So, I hacked the Website stylesheets to generate a
> DocBook index for the site. Not pretty XSL, but my readers love the index.
>

Sorry for bringing this up again.
I did this myself as a DocBook Website customization/rewrite.
Its called tabular-toc:
http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/contrib/xsl/tabular-
toc/

It differs from website in that you have to role your own autolayout.xml,
but after, the entire hierarchical web-site table of contents cascades
down into every html page of every webpage, and chunked book, part, article
across the whole website (using the website "tabular" style).
Only two examples:
http://xtal.sourceforge.net/
http://cima.chem.usyd.edu.au:8080/cif/skunkworks/html/index.html

In addition, you could just feed it a single document, like a book, and
it would build the books TOC, in website tabular style into every
chunked page. (theres an example in with the source)

Of course I did it modifying website in XSLT-1.1 and the new project is
supposed to be XSLT-2, but maybe some of it can be cannibalised?

>
> I realize this is not a trivial thing. Besides the layout, there doesn't
> appear to be much difference between the DocBook and Website (full)
> documents -- mostly a few elements at the top. But the big difference is
> in the processing, and that would no doubt require a lot of work to bridge.

Yeah. It did.

> The benefits just might be worth the effort. Making Website a DocBook
> output option, instead of a separate dialect, would increase its value
> for technical documentation -- a low-tech, frameless alternative to
> Eclipse infocenters and HTML-based help browsers.

Well I thought so.

Neat! That ought to prove my point -- both of us can't be wrong.

Doug wrote:
> On Thu, 20 May 2010, Denis Bradford wrote:
>> Not sure if this the best place to post this, but here goes:
>>
>> Sina, I'm so glad to see active development on Website, it's such a
>> terrific product. As long as you're thinking about its next stage of
>> development, has anyone suggested folding Website into DocBook? I use
>> both all the time, and I think each has features that could enhance the
>> other.
>>
>> I once implemented a doc set that pulled together a bunch of DocBooks
>> and some non-DocBook content using an olink sitemap. I was amazed to
>> learn how powerful sitemaps and generated olink databases are. It
>> occurred to me that they could be used to do far more than enable
>> olinks: they contain all the metadata you need to organize and process a
>> whole doc system -- not unlike Website layouts (and ditamaps, for that
>> matter). On the company web site we served our doc set as an Eclipse
>> infocenter, but I couldn't help thinking how much easier it would have
>> been to post it as a Website.
>>
>> Another example, on the Website side: why should only books and help
>> systems have an index? It's a great navigation tool for an informational
>> web site, too. So, I hacked the Website stylesheets to generate a
>> DocBook index for the site. Not pretty XSL, but my readers love the index.
>>
>
> Sorry for bringing this up again.
> I did this myself as a DocBook Website customization/rewrite.
> Its called tabular-toc:
> http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/contrib/xsl/tabular-
> toc/
>
> It differs from website in that you have to role your own autolayout.xml,
> but after, the entire hierarchical web-site table of contents cascades
> down into every html page of every webpage, and chunked book, part, article
> across the whole website (using the website "tabular" style).
> Only two examples:
> http://xtal.sourceforge.net/
> http://cima.chem.usyd.edu.au:8080/cif/skunkworks/html/index.html
>
> In addition, you could just feed it a single document, like a book, and
> it would build the books TOC, in website tabular style into every
> chunked page. (theres an example in with the source)
>
> Of course I did it modifying website in XSLT-1.1 and the new project is
> supposed to be XSLT-2, but maybe some of it can be cannibalised?
>
>> I realize this is not a trivial thing. Besides the layout, there doesn't
>> appear to be much difference between the DocBook and Website (full)
>> documents -- mostly a few elements at the top. But the big difference is
>> in the processing, and that would no doubt require a lot of work to bridge.
>
> Yeah. It did.
>
>> The benefits just might be worth the effort. Making Website a DocBook
>> output option, instead of a separate dialect, would increase its value
>> for technical documentation -- a low-tech, frameless alternative to
>> Eclipse infocenters and HTML-based help browsers.
>
> Well I thought so.
>
>
>

On 05/20/2010 11:33 AM, Denis Bradford wrote:
> Neat! That ought to prove my point -- both of us can't be wrong.
>

Indeed :) And the forthcoming Publican 2.0 has just such a feature too.
For an example of its output, take a look at the newly revamped Fedora
Documentation site:

http://docs.fedoraproject.org

Each document there is generated as a normal Publican build (using the
--embedtoc and --publish options) and then a single command (publican
install_book) inserts the built document in its various formats into the
directory structure of the site. The install_book command also makes
Publican generate a database entry for a small sqlite database that
Publican then uses to update the tables of contents of the site
automatically. The "Welcome" page is just a DocBook article, built and
inserted into the site in precisely the same way as all the other books
and articles that make up the site.

This tool is currently under heavy development, so any feedback or
suggestions would be really valuable to us right now.

Cheers
Rudi

On Thu, 27 May 2010 01:00:47 +1000
Ruediger Landmann <r.landmann@redhat.com> wrote:

> On 05/20/2010 11:33 AM, Denis Bradford wrote:
> > Neat! That ought to prove my point -- both of us can't be wrong.

Feature creep? Don't you just love it.


regards


--

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Dave,

You and Sina might well be right that DocBook is best kept to a core
system, instead of being extended to accommodate user demands. It looks
to me like the Publican and WebHelp and project represent each approach.

Either way I'm glad I asked the question, otherwise I might have missed
all this very cool development. Thanks to all for your thoughtful responses!

Dave Pawson wrote:
> On Thu, 27 May 2010 01:00:47 +1000
> Ruediger Landmann <r.landmann@redhat.com> wrote:
>
>> On 05/20/2010 11:33 AM, Denis Bradford wrote:
>>> Neat! That ought to prove my point -- both of us can't be wrong.
>
> Feature creep? Don't you just love it.
>
>
> regards
>
>

On Wed, 19 May 2010 17:31:59 -0400
Denis Bradford <denis.bradford@verizon.net> wrote:

> Another example, on the Website side: why should only books and help
> systems have an index? It's a great navigation tool for an
> informational web site, too. So, I hacked the Website stylesheets to
> generate a DocBook index for the site. Not pretty XSL, but my readers
> love the index.

Do you mean index or Toc Denis?
ws has a toc facility.

And since an index is available from the docbook stylesheets, which
are utilised by ws, no reason they shouldn't be included, just
that the wrapper should be a page not an appendix.


hth




--

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Dave Pawson wrote:
> On Wed, 19 May 2010 17:31:59 -0400
> Denis Bradford <denis.bradford@verizon.net> wrote:
>
>> Another example, on the Website side: why should only books and help
>> systems have an index? It's a great navigation tool for an
>> informational web site, too. So, I hacked the Website stylesheets to
>> generate a DocBook index for the site. Not pretty XSL, but my readers
>> love the index.
>
> Do you mean index or Toc Denis?
> ws has a toc facility.
>
> And since an index is available from the docbook stylesheets, which
> are utilised by ws, no reason they shouldn't be included, just
> that the wrapper should be a page not an appendix.

I do mean an index. Even though the index element is available in
website-full, it doesn't work above the scope of a webpage.

As Bob Stayton told me:

"As it currently ships, Website can't collect index entries from the set
of webpage documents and generate a sorted index. "

>
> hth
>
>
>
>

Original Message-----
From: Denis Bradford [mailto:denis.bradford@verizon.net]
Sent: Wednesday, May 19, 2010 4:32 PM
To: DocBook Apps Mailing-List
Subject: Re: [docbook-apps] New Branch: website5

<snip>

> The benefits just might be worth the effort. Making Website a DocBook
> output option, instead of a separate dialect, would increase its value

> for technical documentation -- a low-tech, frameless alternative to
> Eclipse infocenters and HTML-based help browsers.

Hi Denis,
Sorry, just catching up on this thread.

You might be interested in Kasun Gajasinghe's WebHelp GSOC project:
http://docbook.xmlpress.net/tiki-index.php?page=webhelp_proj

This project is turns standard DocBook into user assistance for webapps
and in other situations where you need a crossplatform/crossbrowser help
solution, but is similar to what you want. The index tab is currently a
low-priority item relative to the other features, but is definitely in
the scope. If you've already got some code that creates the content for
an index tab (similar to an the Eclipse or HTML Help index), I'm sure
Kasun would love to see it.

The project will improve on the prototype here:
http://www.thingbag.net/docbook/docbook-webhelp/index.html

The goal is to do it without a frameset, improve the toc, and improve
the search. Kasun and I have currently deprioritized an index tab in
favor of search highlighting, but if you've already done the work,
perhaps the index tab would make it back in.

David

Hi David,

Sorry I missed the WebHelp project -- you're right, the features I had
in mind do suggest user assistance.

I'm not sure what should be in the Index tab, but I'll see if I can help.

Thanks,
Denis


David Cramer wrote:
>
Original Message-----
> From: Denis Bradford [mailto:denis.bradford@verizon.net]
> Sent: Wednesday, May 19, 2010 4:32 PM
> To: DocBook Apps Mailing-List
> Subject: Re: [docbook-apps] New Branch: website5
>
> <snip>
>
>> The benefits just might be worth the effort. Making Website a DocBook
>> output option, instead of a separate dialect, would increase its value
>
>> for technical documentation -- a low-tech, frameless alternative to
>> Eclipse infocenters and HTML-based help browsers.
>
> Hi Denis,
> Sorry, just catching up on this thread.
>
> You might be interested in Kasun Gajasinghe's WebHelp GSOC project:
> http://docbook.xmlpress.net/tiki-index.php?page=webhelp_proj
>
> This project is turns standard DocBook into user assistance for webapps
> and in other situations where you need a crossplatform/crossbrowser help
> solution, but is similar to what you want. The index tab is currently a
> low-priority item relative to the other features, but is definitely in
> the scope. If you've already got some code that creates the content for
> an index tab (similar to an the Eclipse or HTML Help index), I'm sure
> Kasun would love to see it.
>
> The project will improve on the prototype here:
> http://www.thingbag.net/docbook/docbook-webhelp/index.html
>
> The goal is to do it without a frameset, improve the toc, and improve
> the search. Kasun and I have currently deprioritized an index tab in
> favor of search highlighting, but if you've already done the work,
> perhaps the index tab would make it back in.
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>