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 <> 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:
> For additional commands, e-mail:
>
>
--
http://chris.chiasson.name/
