Re: [docbook] making macros

["Chris Chiasson" <chris@chiasson.name>]

Chuck Robey,
If you are looking for an xslt tutorial, I liked the one from Roger L Costello:
http://www.xfront.com/xsl.html

It requires PowerPoint though.

On 4/23/06, Chuck Robey <chuckr@chuckr.org> wrote:
> Per Bothner wrote:
>
> > Steven Cogorno wrote:
> >
> >> You can't do that.  There's no facility for creating "macros" that
> >> group elements together.  You need to include the entire element
> >> structure.
> >
> >
> > One thing one can do is can design a new format that you translate into
> > docbook.  But then the input format isn't docbook.  However, if you want
> > "macros" you can define your own tags, and then write a little xslt
> > script to translate that to standard docbook.
>
> I'm so new to docbook and xml, I am very uneasy to contradict people.
> I've read that one of Sun's major contributionns is in the field of
> documentationm which makes me doubly unwilling to contradict.  I'm a
> programmer, not a document specialist, or editor.  That in mind, here I
> go making a fool of myself ...
>
> Yes, it seems you're absolutely right that docbook provides no such
> facilities, but as a programmer, i really never expected any, and
> instead I began looking over tools to see which might serve to produce
> such a facility  OK, the most difficult would be C, and I would only use
> that because of it's very good portability.  Another possibility would
> be python and the ElementTree, which seems very capable of performing
> this.  However, it seems that the xslt processors couild do this very
> nicely, and many xml environments include a xsl processor right along
> with the rest of their tools, so portability is great.
>
> So, something like zsltproc would serve, if I wrote a good enough xslt
> script, wouldnt it?  Yes, I would want to use an entirely new set of
> elements, which would have to be translated back into docbook elements,
> but that's exactly what I suggested, exactly how the mm macros work with
> groff.
>
> So (note I tend to take a bit to repond usually, fellas), tell me again
> how I'm wrong, please.  I'm stubborn, I know that, but I can see the
> light, given enough time.  Oh, if you consider that I am right, then
> what I'm after is NOT the script to do this, I would write that.  It's
> in the definition of what serve as macros.  I mean, if I chose something
> like mm's chapter entries, or the llist facility, as a macro target, and
> I called this macro 'chuck1' (I couldnt name things at all, guys, I'm
> quite poor at that), say i asked for lists, could I get some help in
> formulating (in maybe meta-language) what might the macro be?
>
> I'll write the processor, but I'm  not a very good docbook author yet.
>
> >
> > This translation could be combined with regular dcobook processing,
> > by adding extra rules to the standard docbook xslt scripts for handling
> > the new tags.
> >
> > An alternative: The GNU texinfo format is a lot less verbose than
> > docbook, and you can translate texinfo into docbook.  (Last year
> > I made numerous fixes to the makeinfo program for its option to
> > generate docbook instead of the default info format.)  However,
> > texinfo is a completely different format from docbook - it's not
> > even XML.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-help@lists.oasis-open.org
>
>


--
http://chris.chiasson.name/