OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] making macros


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]