Gregory Leblanc (gleblanc@cu-portland.edu)
Wed, 12 Jan 2000 20:54:18 -0800
"Paul M. Foster" wrote:
>
> > > What should our favored format be? Obviously, opinions vary. However,
> > > since we're trying to index information, and since presentation should be
> > > less important, I'd vote for XML. It is specifically designed to allow
> > > indexing of information, and has incredible flexibility. The writers of
> > > documentation needn't worry with what format we use, since we are
> > > translating from their format into ours. Real issue is what will make our
> > > indexing job the easiest? I'm inclined to think XML. And forget standards
> > > for XML. You actually don't need a DTD for XML, but we can come up with
> > > one if needed. After all, this is our internal format. Now, if you want
> > > others to write to this format, you'll have to make the DTD simple.
> >
> > Indexing is and likely always will be a manual process. Both SGML and XML
> > provide markup to allow you to specifiy the category in a way that a
> > program can extract it. Hence from a indexing aspect XML and SGML are on
> > equal footing. However, the tool set to work with SGML is much more rich
> > which makes me give it a thumbs up over XML.
> >
>
> You're probably right, and that seems to be the concensus: SGML > XML. I
> don't quite know what DocBook is, but from what I understand it is a
> certain DTD under SGML. Yes?
Yes, and also (soon/sort of) under XML.
>
> Here's the other problem with SGML/Docbook. If you want this to be served
> up in a browser, you'll get a lot more support for doing it in XML than
> SGML. Browsers are starting to support XML, but I don't know that they'll
> ever support SGML or Docbook. And as far as I can see, the browser is
> probably the ideal interface for this stuff.
I'd agree, but there don't seem to be any tools for XML right now. IE 5
has some rudimentary XML capabilities, but not much else.
>
> > > How should the user access the information? I think the standard
> > > technology most widely available today is the browser. It works fairly
> > > well for this purpose and is pretty flexible. That way we are not building
> > > yet another tool. That said, we still will need some sort of cgi or other
> > > back end that will eat one format and turn it into another. This also
> > > means that we will need to have a [thin] document server running on the
> > > local machine.
> >
> > You shouldn't require some daemon on your local system to read
> > documentation IMHO. If you can't export your format to HTML or plain text
> > you are wasting your time. Don't expect to have a mini-knowledge-base
> > running locally on people's system for sometime if ever.
> >
>
> Well, here's the problem. Joe creates program barfoo, and makes his little
> man page for it. (And for the sake of argument, let's say the program is
> quite old but is being regularly maintained.) When Joe updates his
> program, he updates his man pages as well. He sticks it up on Sunsite as a
> tarball. Now, the maintainers of RedHat go out and get his program, make a
> spec file for it, and wrap it in an RPM, and it goes on their distro.
>
> But let's say that everyone decides docbook is the way to go. Is Joe going
> to change his documentation to docbook? Unlikely. Is Red Hat going to take
> the time to translate his man pages into docbook before building the
> RPM? Also unlikely. Which means that if you want to provide the distros
> with a tool to allow them to serve up all the docs in a single way on
> someone's machine, sooner or later you're going to have to build a program
> that goes out and reads those man files (and HOWTOs and info files,
> etc.) and builds some sort of a database or something of them, indexes
> them, and provides a way for a browser to serve them up.
I agree that this (these?) are tools that need writing.
>
> > > Mention was made earlier about categorization in XML being done in
> > > comments. This defeats the purpose of putting it in XML. The tags,
> > > attributes and values need to be part of the ultimate XML document in
> > > order to be of value in indexing.
> >
> > Depends on if your repository is XML aware. If your repository/search
> > engine chokes on XML (which is most of them) then it doesn't matter if
> > categorization info is in native XML or in comment tags as the repoistory
> > engine will just parse the raw text of the document to find what it's
> > looking for.
> >
>
> If that's the case, you might as well put all the docs in straight text
> files. The idea should be to get the document to tell you what's important
> in it, and how it should be categorized.
Agreed, what's the point of using XML or SGML if you're not going to
take advantage of the features it offers.
I snipped a lot, and just left the relavent portions, sorry for not
leaving snip marks.
Greg
This archive was generated by hypermail 2.0b3 on Wed Jan 12 2000 - 23:55:27 EST