[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: if SGML is so great...



> -----Original Message-----
> From: Stein Gjoen [mailto:[email protected]]
> Sent: Friday, May 05, 2000 8:50 AM
> To: Gregory Leblanc
> Cc: [email protected]
> Subject: Re: if SGML is so great...
> 
> Gregory Leblanc wrote:
> > > From: Stein Gjoen [mailto:[email protected]]
> [snip]
> 
> > > My large reply crashed here so I'll rewrite it later. In summary
> > > I feel we need more tags for our specific needs. SGML is
> > > scalable and extensible, right?
> > 
> > Yes, what sorts of tags are you looking for?  I haven't 
> found anything that
> > I want that isn't in DocBook yet (well, except PNG 
> support), but I've only
> > got 1 doc that I'm working on that's big.
> >         Greg
> 
> My long time goal of document accessibility and integration
> have made me think we need tags for
> 
> man pages: <manpage section="1">du</manpage>
> that renders to du(1) in plain text and adds hyperlinks to HTML
> pages and adds to the RELATED list in stub man pages. Some
> commands have multiple man pages, such as mount(2) and mount(8)
> so a section number is needed.

Hmm, ok, I'm CC:'ing the LDP-DocBook list here, because I don't know
everything...yet.  

> HOWTO: <howto>Multi Disk HOWTO</howto>
> that renders to links to that HOWTO in the HTML pages
> and adds to the RELATED list in stub man pages.

Hmm... Now that I think about this, probably the best/only way to accomplish
this one is through the use of some pre-processors.  Basically, before we
run the SGML source through Jade, we run it through a search and replace.
This search and replace goes and finds the text between <howto> and
</howto>, and matches that with a list of the HOWTOs.  It would probably
only apply for the formats that support hyperlinking.  However, in order to
implement this, we have to have a list that we say "This is the official
list of the names of the HOWTOs".  If we do that, we have to send it to at
very least these lists (discuss and announce), so that authors can make sure
that we've got the right names for the HOWTOs.  

> In addition I wish the <file> tag rendering was changed to
> file:///pathoffile URL in the HTML document, shown in courier
> or similar font. This too would be handy in stub man pages.

That should be a trivial change for DocBook, maybe somebody can shed some
light on LinuxDoc.  

> Generally I prefer filenames and commands to be rendered in
> courier or a similar non proportional font.
> 
> Rendering of the hyperlinks would be installation dependent,
> so on the LinuxDoc web pages it would refer to sample files
> wheras on a home system it would point to the actual file.
> 
> Likewise hyperlinks to HOWTOs and man pages would be rendered
> as appropriate for the installation, be it with cgi-scripts,
> calls to xman or the like.

Hmm, sounds a little complex.  The changing how things are rendered is easy
with DocBook.  The changing where things point as appropriate to the
installation sounds really difficult.  

> Today the SGML functionality is used just for conversion, we
> have hardly started tapping the true power of SGML and as such
> it is not surprising some are sceptical to this platform.
> Even LaTeX offers in some areas superior conversion features
> if that is all we are after.
> 
> From what I can see we don't even use SGML for searching, is
> this correct?

Yep, because we don't have an SGML aware search engine.  I don't have the
skills to write one, and don't know where to find people who could.

> To start tapping the power of SGML we need to recruit people
> to make these scripts and changes so we authors don't have to
> spend our time on it.
> 
> My NetHelp sample was rendered by hand and it was very tedious.
> If what people say about the superiority of SGML, this should
> be simple for the experts to whip up quickly.
> 
> When I write the next update for submission to LWN I'll add a
> bit about this unless I get a lot of protests. As usual previews
> will come here first.

I've got no complaints.
Later,
	Greg


--  
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]