Docbook discussion

Roland Mainz | 3 Aug 2009 02:25

DocBook-to-Wiki XSL stylesheet ?


Hi!

----

AFAIK someone was working on a DocBook-to-Wiki XSL stylesheet... does
anyone here know where I can pointers to that work ?

----

Bye,
Roland

--

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz <at> nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

headers

Eric Johnson | 3 Aug 2009 15:04

RE: DocBook-to-Wiki XSL stylesheet ?

This project does confluence wiki to docbook:
http://fusesource.com/wiki/display/CONFDOC/Home 

-----Original Message-----
From: gisburn <at> jupiterb48.nrubsig.org
[mailto:gisburn <at> jupiterb48.nrubsig.org] On Behalf Of Roland Mainz
Sent: Sunday, August 02, 2009 8:26 PM
To: DocBook mailinglist
Subject: [docbook] DocBook-to-Wiki XSL stylesheet ?

Hi!

----

AFAIK someone was working on a DocBook-to-Wiki XSL stylesheet... does
anyone here know where I can pointers to that work ?

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) roland.mainz <at> nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

---------------------------------------------------------------------

(Continue reading)

headers

Andy Dingley | 3 Aug 2009 15:24

RE: DocBook-to-Wiki XSL stylesheet ?

> AFAIK someone was working on a DocBook-to-Wiki XSL stylesheet... does
> anyone here know where I can pointers to that work ?

What do we mean by Wiki?  Mediawiki? Also is this the non-XML wikitext
that wiki editors see, or the export / import XML format that's used for
content dumps and replication?

headers

Scott Hudson | 4 Aug 2009 00:10

Re: DocBook Technical Committee Meeting Minutes: 15 July 2009

Cedric,

would it be possible to have you post your comments to the official 
OASIS comment list?

http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=docbook

I want to make sure we are following proper OASIS procedures.

Thanks and best regards,

--Scott
Chair, DocBook Publishers subcommittee

Mimil Mimil wrote:
> Hello,
>
> I just have a little comment on  8.Publishing Subcommittee report ...  
> Scott suggests everyone read it and provide comments.
>
> With an external view (no knowledge of publishing) I wondered what is 
> the real motivation to have 3 distinct elements (dialogue, drama, 
> poetry) because they seem to have the same goal "speeches" and also 
> have the same xml definition in the spec 
> (http://docs.oasis-open.org/docbook/specs/publishers-1.0-spec-cd-01.pdf)
> If the definition is the same, isn't the role attribute sufficient 
> within a single dialogue element?
> Or is it a choice made to simplify the stylesheet work as these 
> elements really need a different printing layout?
>

(Continue reading)

headers

Dongsheng Song | 4 Aug 2009 03:17

Re: DocBook-to-Wiki XSL stylesheet ?

I guess he mean like this:

http://doc-book.sourceforge.net/homepage/

On Mon, Aug 3, 2009 at 9:24 PM, Andy Dingley<dingbat <at> codesmiths.com> wrote:
>> AFAIK someone was working on a DocBook-to-Wiki XSL stylesheet... does
>> anyone here know where I can pointers to that work ?
>
> What do we mean by Wiki?  Mediawiki? Also is this the non-XML wikitext
> that wiki editors see, or the export / import XML format that's used for
> content dumps and replication?
>

headers

Dave Pawson | 4 Aug 2009 06:29

Re: DocBook Technical Committee Meeting Minutes: 15 July 2009


> Mimil Mimil wrote:
>> Hello,
>>
>> I just have a little comment on 8.Publishing Subcommittee report ...
>> Scott suggests everyone read it and provide comments.
>>
>> With an external view (no knowledge of publishing) I wondered what is
>> the real motivation to have 3 distinct elements (dialogue, drama,
>> poetry) because they seem to have the same goal "speeches" and also
>> have the same xml definition in the spec
>> (http://docs.oasis-open.org/docbook/specs/publishers-1.0-spec-cd-01.pdf)
>> If the definition is the same, isn't the role attribute sufficient
>> within a single dialogue element?
>> Or is it a choice made to simplify the stylesheet work as these
>> elements really need a different printing layout?
>>
>> Best regards,
>> Cédric,

I can appreciate the difference between poetry and drama.
Dialogue and drama (to me) seems less clear?
   dialogue seems to be a part of drama, except I've usually
seen it marked up as speech.

regards

regards

--

--

(Continue reading)

headers

Kate.Wringe | 4 Aug 2009 17:26

Re: Why do formalparas only allow one para?

Hi Bob,

Thank you for your suggestions and patience. My original inquiry was perhaps motivated more by authoring issues than by formatting issues; however,
these two issues often overlap and are difficult to separate. Also, it is not always apparent why some elements have the restrictions that they do (e.g., why does
para allow block elements like mediaobject?).

At the end of this discussion, I still don't understand the purpose of formalparas and because of usability issues(i.e., there is a problem with distinguishing the paras that follow them),
I'm now inclined to avoid them entirely. Likely, I will suggest to my team that we use variablelists or sidebar elements instead of formalparas; however, I'm not keen on either alternative as they
will require us to use attributes. For our content, variablelist is probably the better choice; although the writers won't like it because they can't just drag and drop a varlistentry as freely as you
can with formalpara (i.e., you have to ensure that the variablelist container exists).

Thanks again,
Kate

"Bob Stayton" <bobs <at> sagehill.net>

07/28/2009 08:07 PM

To	<Kate.Wringe <at> sybase.com>
cc	"David Cramer" <dcramer <at> motive.com>, <docbook <at> lists.oasis-open.org>, "Jirka Kosek" <jirka <at> kosek.cz>, "Scott Hudson" <scott.hudson <at> flatironssolutions.com>
Subject	Re: [docbook] Why do formalparas only allow one para?

Hi Kate,
I was going to suggest you use sidebar with a role attribute, but your earlier mail said you were already doing that. I think sidebar is semantically a good match for "defining/explaining/introducing a term/option/clause/concept". Most people think of sidebar as formatted to the side, but it does not have to be. Since DocBook XML markup is not meant to indicate formatting, a sidebar is intended to indicate content "out of the regular flow", and which *might* be formatted to the side.

Your original inquiry about formalpara did not seem to be motivated by formatting issues, but by authoring issues. You wanted a container for multiple paragraphs so you could move them as a unit. That kind of need is pretty common, but is often hard to implement in element structure. I have worked with content in which it was the writing style to precede every figure and table with a paragraph that explains the relevance of the following figure or table ("The following figure shows ..."). You can see how those also have to stay together to make sense, but trying to implement that combination as an element container would be kind of awkward. Since DocBook does not support an arbitrary <div> container, it usually falls on the author to pay attention when moving content around.

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net

----- Original Message -----
From: Kate.Wringe <at> sybase.com
To: Bob Stayton
Cc: David Cramer ; docbook <at> lists.oasis-open.org ; Jirka Kosek ; Scott Hudson
Sent: Tuesday, July 28, 2009 8:03 AM
Subject: Re: [docbook] Why do formalparas only allow one para?

Hi Bob,

Thank you for your advice and suggestion to submit a RFE to the DocBook committee.

Perhaps my team isn't using formalparas correctly. Could you explain a bit more as to how they should be used?

We use formalparas for defining/explaining/introducing a term/option/clause/concept. It's the assumption/restriction that this can always be done in a
single para that is forcing us to resort to other tagging instead (e.g., like just bolding the term inline in a para, which isn't ideal, or needlessly creating variablelists).

We desire multi-para formalparas (to embed a definition in the larger topic, but differentiated style). We could then bring in the formalpara margins by 3 or 4 spaces to differentiate it from regular paras that follow, etc. :))

Thanks again,
Kate

"Bob Stayton" <bobs <at> sagehill.net>

07/25/2009 12:18 PM

To	<Kate.Wringe <at> sybase.com>
cc	"David Cramer" <dcramer <at> motive.com>, <docbook <at> lists.oasis-open.org>, "Jirka Kosek" <jirka <at> kosek.cz>, "Scott Hudson" <scott.hudson <at> flatironssolutions.com>
Subject	Re: [docbook] Why do formalparas only allow one para?

Hi Kate,
If you want this to be considered by the DocBook Technical Committee for inclusion in future versions of DocBook schemas, please file a RFE on the DocBook SourceForge site:

https://sourceforge.net/tracker/?group_id=21935 (select "RFEs")

You must be a member to submit new items.

I can tell you that such generic container elements have been discussed in the past but never adopted. Be sure to include all of your arguments and use cases to support your request.

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net

----- Original Message -----
From: Kate.Wringe <at> sybase.com
To: Dave Pawson
Cc: David Cramer ; docbook <at> lists.oasis-open.org ; Jirka Kosek ; Scott Hudson
Sent: Friday, July 24, 2009 6:17 AM
Subject: Re: [docbook] Why do formalparas only allow one para?

What we need is a free-floating container element that takes a title and allows other block elements (e.g, indexterms, paras, lists, etc.,) within it.
We want a container element because it is useful for reuse and relocation of content. We want the element to be free-floating because we need to be able
to put the element anywhere and have other content elements follow it (including itself).

The problem with bridgeheads is that they are just titles and you can't show the relationship between the title and the content that follows it. To xinclude you'd have
xinclude the bridgehead as well as each element that follows. We would prefer to have one container element that you could put an ID on and be able to conditionalize it and/or xinclude it.

We actually have two cases where we need free-floating container elements with titles:
1) One where the title is not inline -- this element would be akin to simplesect if simplesect was not non-floating.
2) One where the title is inline -- this element would be akin to formalpara if formalpara allowed you to have more than one para and allowed other block elements.

Currently for 1) we use sidebars instead of bridgeheads because we needed a sub-section-level container element with a title, that could be used anywhere and multiple times within a section.
Simplesect, because it is non-floating, did not meet our requirements.

We are looking for a solution for 2) because formalparas do not meet our needs, but they are the best alternative we have right now.

Thanks again,

Kate

Dave Pawson <davep <at> dpawson.co.uk>

07/24/2009 12:25 AM

To	David Cramer <dcramer <at> motive.com>
cc	Scott Hudson <scott.hudson <at> flatironssolutions.com>, Kate.Wringe <at> sybase.com, Jirka Kosek <jirka <at> kosek.cz>, docbook <at> lists.oasis-open.org
Subject	Re: [docbook] Why do formalparas only allow one para?

Why not use a bridgehead and multiple paras?

formalpara is singular? Hence one para?

regards

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

headers

Bob Stayton | 15 Aug 2009 19:41

DocBook Technical Committee Meeting Agenda: 19 August 2009

DocBook Technical Committee Meeting Agenda: 19 August 2009
=============================================================

The DocBook Technical Committee will meet on Wednesday, 19 August 2009 at
01:00p EDT (10:00a PDT, 17:00GMT, 18:00BST, 19:00CEST, 02:00JST+,
022:30p India+) for 90 minutes.

Attendance at teleconferences is restricted to members
(and prospective members) of the committee.

This is the phone number for Wednesday's DocBook TC call:

Phone: +1-719-387-5556
 Code: 902213

The DocBook TC uses the #docbook IRC channel on
irc.freenode.org.  The IRC channel is used for exchanging
URIs, providing out-of-band comments, and other aspects
of the teleconference, so please join us there if at
all possible.

Agenda

1. Roll call
2. Accepting the minutes [1] of the previous meeting.
3. Next meeting: 16 September 2009
4. Review of the agenda.
5. Review of open action items

  a. Norm to work with Mary to make Publishing Subcommittee
     schema a Committee Working Draft.

  b. Norm to work with Keith and Scott to update the OASIS committee
     site to make the Publishing Subcommittee Working Draft
     publicly available.

  c. Norm to put the new backwards compatibility policy in the spec.

  d. Norm to put the new backwards compatibility policy in the
     reference documentation.

  e. Norm to take a look at the inlines and make a proposal
     regarding RFE 2791288.

  f. Larry to create a new assembly example for next meeting.

  g. Norm to create a DocBook 5 customization layer
     with topic, so we can experiment.

  h. Bob to present the proposal to the docbook
     mailing list when Norm has the customization done.

6.  DocBook 5.0 standards update.

7.  New edition of DocBook: The Definitive Guide 

8.  Publishing Subcommittee report.

9. Using a map for modular DocBook.

10. Transclusion feature (REF #2820947)

11. Add topic element (RFE #2820190).

12.  Review of Requests for Enhancement

    To browse a specific RFE, enter the URL (on one line):

      http://sourceforge.net/tracker/index.php?func=detail&;
      group_id=21935&atid=384107&aid=XXXX

    RFEs to revisit for 6.0
      1907003  biblioid content model too broad  

    RFEs to be considered 
      1679665  Add better support for modular documentation  
      2770858  Add limited emphasis to ubiquitous inlines 
      2791288  add quote to corpauthor and gui elements 
      2820190  add a topic element  
      2820947  Ability to transclude text 
      2821653  indexterms in footnotes 

-----

[1] http://lists.oasis-open.org/archives/docbook-tc/200907/msg00019.html

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net

headers

Daniel Leidert | 17 Aug 2009 16:10

Copyright/license of transition guide?

Hi,

To package the DocBook 5.0 transition guide together with the schemas
and DTD for Debian, I need to know copyright and license information.
Does the license/copyright statement from the schemas apply to the Howto
too?

TIA and regards, Daniel

headers

Dominic Marcotte | 17 Aug 2009 23:22

Custom XSL: Is there a way to wrap the content?

Hello,

I want to create a custom XSL to wrap my generated html content by a div. I need this for the display.

With this...

<?xml version="1.0" encoding="UTF-8"?> <?oxygen RNGSchema=MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "www.oasis-open.org" "http://www.oasis-open.org/docbook/xml/5.0/rng/docbook.rng" type="xml"?> <article xmlns=MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "docbook.org" "http://docbook.org/ns/docbook"     xmlns:xlink=MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "www.w3.org" "http://www.w3.org/1999/xlink" version="5.0">     <info>         <title>Article Template Title</title>     </info>     <section>         <title>Section1 Title</title>         <para>Text</para>     </section> </article>
I want to generate this

<html><head>     <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">     <title>Article Template Title</title>     <meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.1"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> <div class="my_added_div"> <-----------     <div class="article" title="Article Template Title">         <div class="titlepage">             <div>                 <div>                     <h1 class="title"><a name="d0e2"></a>Article Template Title</h1>                 </div>             </div>             <hr>         </div>         <div class="section" title="Section1 Title">             <div class="titlepage">                 <div>                     <div>                         <h2 class="title" style="clear: both"><a name="d0e6"></a>Section1 Title</h2>                     </div>                 </div>             </div>             <p>Text</p>         </div>     </div> </div> <----------- </body> </html>
I cannot do that with the Templates for HTML headers and footers.

My dream is to do...

<xsl:template name="user.body.content">
    <div class="my_added_div">
       <xsl:apply-templates />
    </div>
</xsl:template>

Is there a way to wrap the content?

Thanks

Dominic

41	June 2013
8	May 2013
52	April 2013
22	March 2013
9	February 2013
28	January 2013
22	December 2012
11	November 2012
10	October 2012
9	September 2012
24	August 2012
24	July 2012
21	June 2012
55	May 2012
17	April 2012
46	March 2012
7	February 2012
41	January 2012
67	December 2011
17	November 2011
29	October 2011
15	September 2011
41	August 2011
23	July 2011
20	June 2011
30	May 2011
9	April 2011
36	March 2011
43	February 2011
35	January 2011
26	December 2010
16	November 2010
18	October 2010
16	September 2010
20	August 2010
54	July 2010
29	June 2010
24	May 2010
33	April 2010
37	March 2010
29	February 2010
82	January 2010
33	December 2009
37	November 2009
21	October 2009
29	September 2009
21	August 2009
56	July 2009
42	June 2009
24	May 2009
41	April 2009
26	March 2009
30	February 2009
35	January 2009
12	December 2008
36	November 2008
53	October 2008
35	September 2008
43	August 2008
62	July 2008
29	June 2008
21	May 2008
9	April 2008
38	March 2008
19	February 2008
74	January 2008
62	December 2007
88	November 2007
81	October 2007
84	September 2007
62	August 2007
48	July 2007
18	June 2007
29	May 2007
53	April 2007
83	March 2007
8	February 2007
14	December 2006
4	June 2006
6	May 2006
2	April 2006
13	February 2006
4	November 2005
32	September 2005
26	August 2005
66	July 2005
50	June 2005
53	May 2005
82	April 2005
6	March 2005
1	March 2004
187	March 2003
162	February 2003
133	January 2003
137	December 2002
136	November 2002
152	October 2002
217	September 2002
200	August 2002
188	July 2002
179	June 2002
125	May 2002
108	April 2002
145	March 2002
116	February 2002
1	January 2001

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31