Slashdot Mirror

The idea of using styles in a wordprocessor is about creating document structure -- the most usable interface I've seen for this the interface for Conglomerate.org. It's pretty fancy, and avoids trying to look like print or web when these days people want to publish to both from a single source. It concentrates them on the structure, which is what cross-platform publishing is all about.

That's only because you're not editing them with the proper tool.

Yeah, there are several XML options, including those that can be XSL'd to HTML or PDF; I think the problem is that it's just not easy to create good XML. I'm holding my breath that someday Conglomerate will change that for Linux/etc. but for Windows your best option is still XMetaL for XML text, and it ain't cheap (or at least, it wasn't.)

http://www.conglomerate.org/

It's in no stable state now, but they've got the interface right, and they seem eager.

• Arbortext Epic Editor
• SoftQuad XMetal or Corel XMetal
• EpcEdit XML/SGML Editor
• Altova Authentic
• XmlMind XML Editor (Standard version is free)
• Morphon XML Editor
• TimeLux XPress
• GenDoc (open source, could be nice if someone wrote a docbook plugin)
• Conglomerate (open source project which seems to be resurrected, nothing available now though)
• ExcoSoft XML Client (as far as I can tell from the website...)
• SoftMagic SendStory
• 
  Anyone has experience with these? (or others that are missing from the list).

I was looking for the same thing not too long ago, and came across Conglomerate, which despite its web page, is no longer dead, and back under development.

I've had a few problems getting it compiled/running well, but from what I've seen, it looks like it's a fairly decent bit of code, so once it gets some polish, it could be pretty handy.

And both (LaTeX and Emacs) have shown absolutely no interest in becoming mass-market cross-platform applications, unlike Open Office. Because of this people use MS Office, on the MS platform, support MS-only formats, and MS-only drivers, and surrounding 'limpet' software that only has to run on MS Windows. Even Linus agrees that most people don't care about the kernel, most people just use applications. What applications do most people need at the least? Email / Browser / Office. It has nothing to do with hate of microsoft, it has to do with cross-platform and an appreciation of not being locked in. Sun keeps screwing around with OpenOffice, they just can't seem to make their minds up.

ps. LaTeX doesn't have to be destroyed to be mass market. You could have a beautiful and usable interface like this, but every version I have seen of it I wouldn't doesn't have a good interface. The software is good, it's excellent, but no one will ever get to see it when it's cloaked behind something so unfriendly. A usable and pretty high-level XML word-processer is the killer app.

-- Not Bruce (sorry kids!)

Check out the screenshots... of this faded and dead project (of a few months). I really wish they would pick this up again and push it towards Docbook with XSL transformations.

The web publishing cycle is a huge market.

Forget about how do you build the repository -- that's easy. (Well, okay, non-trivial, but with databases, cvs, and even just simple shared folders, storing the docs is the least of your worries).

I still maintain that the biggest hurdle in any standardized document system (especially if you include multiple concurrent authors) is the front-end editor. I wrote a simple (and highly buggy, I'll admidt, so you who know me keep your traps shut!) VB application that provided a multi-user front end to a database. The back-end (PHP) pulled all the appropriate rows for any given doc together and mashed it into a nice, navigable HTML document. I even had PDF support at one time (but it was even flakier than the GUI).

However, it was not XML, so it was REALLY limited in how easy it was to create new views on the data. The biggest problem I ran into was trying to find a good GUI editor -- this thing was written for security engineers, not HTML experts, and I wanted them to concentrate on content, not tags. I eventually settled (and settled is the right word) on the Microsoft DHTML control. Worked well enough for the time (two years ago at this point), but I still think half my problems stemmed from that widget, or bad interface programming to it. The advantage? WYSIWYG (more or less) editing. Seamless multi-user editing of the same document (well, okay, we had some record locking issues. :) ) But again, the long pole of the tent was the editor widget.

Since then, I've wanted very much to rewrite the thing to handle full XML, and I understand there's an effort underway to do just that (I've since moved to different pastures), but it's slow going. I've looked at current technology (ABIword, for example), and i'm just not convinced that it's going to be easy to get a good semi-WYSIWYG XML editor going. At least not on the cheap.

Some time ago was posted here an app called Conglomorate, which I still think has about the best approach to visually representing an XML document. But it hasn't been updated in forever, and was slow/buggy the one time I played with it. More recently, the XMLmind XML Editor (XXE) has shown a lot of promise, even including CSS files for editing DocBook XML. They even have source available. Again, goes a long way to letting you edit diverse XML files in a logical way -- not by forcing you to look at ugly tree-views of an XML file, like so many first-generation editors. Finally, the latest XML Spy editor beta goes a bit father even than XXE, using a full XSLT transform to provide a WYSIWYG format for XML files. Theoretically, with this, you should be able to display any of your documents in whichever approach you like -- full WYSIWYG, tables, trees, block labels, whatever.

Of course, neither of these latter tools work in a concurrent editing fashion. But that's a "minor" enhancement -- put together a robust DB back end, allow for good record locking, editor-to-editor communications for lock management, transaction log to allow back-out of changes, etc. Lots of possibilities. Take XXE, put this kind of capability on the back-end, an integrated login and document management system, and you've got a kick-ass document solution. Work the backend to allow for multi-stage review and publishing, and provide output engines for HTML, PDF, WAP, whatever, serve different subtrees of the system to, say, internal project web servers, external web servers, sales and marketing (for glossies), etc., and everyone can manage everything, real-time, GUI, with one tool.

But I dream.

(seriously -- if anyone's really working this, I'd love to help. I just wanna use it at home for my own web pages.)

More worthy, full document management system than the efforts being put into word processing.

Conglomerate

I recently found conglomerate. It looks like exactly what you want. It's probobly a little rough around the edges, but it's an open source project, so you've got the code if you want it. I've found that the site is a little iffy. Sometimes it's up sometimes it's down. It's in Brazil, I think.

Whoops. I clicked on Submit by accident, but thought I caught it in time. Guess not. Read this message instead... :-\

I cannot argue with the lack of functional, friendly editors for
either *ML or its stylesheets. Have we identified a need? Is there a
place for a WYSIWYG word processor which manages the tension between
local formatting and reuse for the user, which integrates and
abstracts away the management of DTD/schemas and stylesheets? Maybe,
maybe not. Does our friend want to post his chemistry paper to the
web, archive it? Does giving LyX an *ML fluent backend accomplish this
goal?

Well, some applications do keep their documents in an SGML or XML
format: AbiWord saves files
with an abw extension that are (according to file)
``exported SGML document text''. AbiSource's FAQ
states that their native file format is XML (and gives some reasons
and a link to their
DTD). A brief example document might look like the following:

<!-- ================================================== =================== -->

<!-- This file is an AbiWord document. -->

<!-- AbiWord is a free, Open Source word processor. -->

<!-- You may obtain more information about AbiWord at www.abisource.com -->

<!-- You should not edit this file by hand. -->

<!-- ================================================== =================== -->

<!-- Build_ID = (none) -->

<!-- Build_Version = 0.7.7 -->

<!-- Build_Options = LicensedTrademarks:Off Debug:Off -->

<!-- Build_Target = /project/debian/abiword-0.7.7/abi-0.7.7/src/Linux_ 2.3.6_ppc_OBJ/obj -->

<!-- Build_CompileTime = 12:48:12 -->

<!-- Build_CompileDate = Dec 16 1999 -->

<abiword version="0.7.7">

<section>

<p style="Heading 1">This is a major heading, level one</p>

<p></p>

<p>So, here we have a basic AbiWord document.</p>

<p></p>

<p>"Say, Joe, whaddya know?" Hmm, no smart quotes.</p>

<p></p>

<p style="Heading 2">This is a second-level header</p>

<p></p>

<p>Some more plain text that isn't particularly important.</p>

<p></p>

<p style="Heading 3">Here we have a third-level header</p>

<p style="Normal"></p>

<p style="Normal">And we're back to normal.</p>

<p style="Normal"></p>

<p style="Normal"></p>

<p style="Normal">Out of curiosity, we have <c props="font-weight:bold">some bold text,</c> and <c props="font-style:italic">some italic text.</c></p>

<p style="Normal"></p>

<p style="Plain Text">This text is in the plain text style, which is kind of like \texttt. Bizarre.</p>

<p style="Normal"></p>

<p style="Block Text">And this text is in the block text style, which I'm guessing is like quotation or quote or <blockquote>.</p>

<p style="Normal"></p>

<p style="Normal">Looks like I was right.</p>

</section>

</abiword>

AbiWord's interface is very Word-like, including rulers for margin
adjustment and toolbars with buttons to open, save, and close files;
appear in multiple columns; make text italic, bold, underlined, and so
forth; and set justification. As such, it's very useful for people
moving from other computing platforms who are looking for replacements
for their commercial word-processing applications, but that also means
that it's not ideal as a structured SGML/XML editor (without a
significant amount of additional work, at any rate).

Other applications, such as Dia, a diagramming
application, save their output in recognizable XML (file says
``XML 1.0 document text'', and the document looks like XML when you
view it in a text editor).

Finally, as I mentioned previously, Conglomerate is specifically
designed to be an XML editor, but isn't really available yet.
Conglomerate looks like an SGML editor -- it clearly shows the tagging
of various bits of text.

In any case, I'm not sure I'm convinced that a WYSIWYG editor is
the best approach -- I think some sort of simplified syntax (such as
that provided by LaTeX) that could easily be translated to SGML or XML
might be a better solution. I like the ideas shown in the screenshots of
Conglomerate because they make the structural and other markup
very clear without the illusion of control that would be provided by
an interface such as AbiWord's. What I think is needed is an
interface that would make the structure and other tags clear, and
allow tags to be inserted by typing them directly (presumably with
some macro features) or selecting from a mutable menu or palette (that
would only present viable options for the selected text or cursor
location). Although I hate to say it (because I hate them), I don't
know that ``wizards'' would be entirely out of place for help with
some complicated constructs.

I do think that you're right to believe that such tools will evolve
themselves into existence, and that, as they do, more and more people
may find themselves using SGML or XML without even realizing that they
are. Time will tell.

I find it absolutely incredibly that a publisher is shooting
plates from 600dpi laser output, although I can probably guess the
publisher.

That makes two of us. I was surprised that they didn't want the
LaTeX source, shocked when I found out they didn't want the
PostScript, and horrified when I found out what they actually
used.

Whoops. I clicked on Submit by accident, but thought I caught it in time. Guess not. Read this message instead... :-\

I cannot argue with the lack of functional, friendly editors for
either *ML or its stylesheets. Have we identified a need? Is there a
place for a WYSIWYG word processor which manages the tension between
local formatting and reuse for the user, which integrates and
abstracts away the management of DTD/schemas and stylesheets? Maybe,
maybe not. Does our friend want to post his chemistry paper to the
web, archive it? Does giving LyX an *ML fluent backend accomplish this
goal?

Well, some applications do keep their documents in an SGML or XML
format: AbiWord saves files
with an abw extension that are (according to file)
``exported SGML document text''. AbiSource's FAQ
states that their native file format is XML (and gives some reasons
and a link to their
DTD). A brief example document might look like the following:

<!-- ================================================== =================== -->

<!-- This file is an AbiWord document. -->

<!-- AbiWord is a free, Open Source word processor. -->

<!-- You may obtain more information about AbiWord at www.abisource.com -->

<!-- You should not edit this file by hand. -->

<!-- ================================================== =================== -->

<!-- Build_ID = (none) -->

<!-- Build_Version = 0.7.7 -->

<!-- Build_Options = LicensedTrademarks:Off Debug:Off -->

<!-- Build_Target = /project/debian/abiword-0.7.7/abi-0.7.7/src/Linux_ 2.3.6_ppc_OBJ/obj -->

<!-- Build_CompileTime = 12:48:12 -->

<!-- Build_CompileDate = Dec 16 1999 -->

<abiword version="0.7.7">

<section>

<p style="Heading 1">This is a major heading, level one</p>

<p></p>

<p>So, here we have a basic AbiWord document.</p>

<p></p>

<p>"Say, Joe, whaddya know?" Hmm, no smart quotes.</p>

<p></p>

<p style="Heading 2">This is a second-level header</p>

<p></p>

<p>Some more plain text that isn't particularly important.</p>

<p></p>

<p style="Heading 3">Here we have a third-level header</p>

<p style="Normal"></p>

<p style="Normal">And we're back to normal.</p>

<p style="Normal"></p>

<p style="Normal"></p>

<p style="Normal">Out of curiosity, we have <c props="font-weight:bold">some bold text,</c> and <c props="font-style:italic">some italic text.</c></p>

<p style="Normal"></p>

<p style="Plain Text">This text is in the plain text style, which is kind of like \texttt. Bizarre.</p>

<p style="Normal"></p>

<p style="Block Text">And this text is in the block text style, which I'm guessing is like quotation or quote or <blockquote>.</p>

<p style="Normal"></p>

<p style="Normal">Looks like I was right.</p>

</section>

</abiword>

AbiWord's interface is very Word-like, including rulers for margin
adjustment and toolbars with buttons to open, save, and close files;
appear in multiple columns; make text italic, bold, underlined, and so
forth; and set justification. As such, it's very useful for people
moving from other computing platforms who are looking for replacements
for their commercial word-processing applications, but that also means
that it's not ideal as a structured SGML/XML editor (without a
significant amount of additional work, at any rate).

Other applications, such as Dia, a diagramming
application, save their output in recognizable XML (file says
``XML 1.0 document text'', and the document looks like XML when you
view it in a text editor).

Finally, as I mentioned previously, Conglomerate is specifically
designed to be an XML editor, but isn't really available yet.
Conglomerate looks like an SGML editor -- it clearly shows the tagging
of various bits of text.

In any case, I'm not sure I'm convinced that a WYSIWYG editor is
the best approach -- I think some sort of simplified syntax (such as
that provided by LaTeX) that could easily be translated to SGML or XML
might be a better solution. I like the ideas shown in the screenshots of
Conglomerate because they make the structural and other markup
very clear without the illusion of control that would be provided by
an interface such as AbiWord's. What I think is needed is an
interface that would make the structure and other tags clear, and
allow tags to be inserted by typing them directly (presumably with
some macro features) or selecting from a mutable menu or palette (that
would only present viable options for the selected text or cursor
location). Although I hate to say it (because I hate them), I don't
know that ``wizards'' would be entirely out of place for help with
some complicated constructs.

I do think that you're right to believe that such tools will evolve
themselves into existence, and that, as they do, more and more people
may find themselves using SGML or XML without even realizing that they
are. Time will tell.

I find it absolutely incredibly that a publisher is shooting
plates from 600dpi laser output, although I can probably guess the
publisher.

That makes two of us. I was surprised that they didn't want the
LaTeX source, shocked when I found out they didn't want the
PostScript, and horrified when I found out what they actually
used.

I cannot argue with the lack of functional, friendly editors for either *ML or its stylesheets. Have we identified a need? Is there a place for a WYSIWYG word processor which manages the tension between local formatting and reuse for the user, which integrates and abstracts away the management of DTD/schemas and stylesheets? Maybe, maybe not. Does our friend want to post his chemistry paper to the web, archive it? Does giving LyX an *ML fluent backend accomplish this goal?

Well, some applications do keep their documents in an SGML or XML format: AbiWord saves files with an abw extension that are (according to file) ``exported SGML document text''. AbiSource's FAQ states that their native file format is XML (and gives some reasons and a link to their DTD). A brief example document might look like the following:

<!-- ================================================== =================== --> <!-- This file is an AbiWord document. --> <!-- AbiWord is a free, Open Source word processor. --> <!-- You may obtain more information about AbiWord at www.abisource.com --> <!-- You should not edit this file by hand. --> <!-- ================================================== =================== --> <!-- Build_ID = (none) --> <!-- Build_Version = 0.7.7 --> <!-- Build_Options = LicensedTrademarks:Off Debug:Off --> <!-- Build_Target = /project/debian/abiword-0.7.7/abi-0.7.7/src/Linux_ 2.3.6_ppc_OBJ/obj --> <!-- Build_CompileTime = 12:48:12 --> <!-- Build_CompileDate = Dec 16 1999 --> <abiword version="0.7.7"> <section> <p style="Heading 1">This is a major heading, level one</p> <p></p> <p>So, here we have a basic AbiWord document. Jeez, its spell checker doesn't even know about the spelling of the application's name? That's kind of lame.</p> <p></p> <p>"Say, Joe, whaddya know?"</p> <p></p> <p style="Heading 2">This is a second-level header</p> <p></p> <p>Some more plain text that isn't particularly important.</p> <p></p> <p style="Heading 3">Here we have a third-level header</p> <p style="Normal"></p> <p style="Normal">And we're back to normal.</p> <p style="Normal"></p> <p style="Normal"></p> <p style="Normal">Out of curiosity, we have <c props="font-weight:bold">some bold text,</c> and <c props="font-style:italic">some italic text.</c></p> <p style="Normal"></p> <p style="Plain Text">This text is in the plain text style, which is kind of like \texttt. Bizarre.</p> <p style="Normal"></p> <p style="Block Text">And this text is in the block text style, which I'm guessing is like quotation or quote or <blockquote>.</p> <p style="Normal"></p> <p style="Normal">Looks like I was right.</p> </section> </abiword>

AbiWord's interface is very Word-like, including rulers for margin adjustment and toolbars with buttons to open, save, and close files; appear in multiple columns; make text italic, bold, underlined, and so forth; and set justification. As such, it's very useful for people moving from other computing platforms who are looking for replacements for their commercial word-processing applications, but that means that it's not ideal as a structured SGML/XML editor (without a significant amount of additional work, at any rate).

Other applications, such as Dia, a diagramming application, save their output in recognizable XML (file says ``XML 1.0 document text'', and the document looks like XML when you view it in a text editor).

Finally, as I mentioned previously, Conglomerate is specifically designed to be an XML editor, but isn't really available yet. Conglomerate looks like an SGML editor -- it clearly shows the tagging of various bits of text.

I find it absolutely incredibly that a publisher is shooting plates from 600dpi laser output, although I can probably guess the publisher.

That makes two of us. I was surprised that they didn't want the LaTeX source, and shocked when I found out they didn't want the PostScript, and horrified when I found out what they actually used.

If things like conglomerate finished. Just see their preview and I think it's so cool. So rather than bastarding MS Word take a lot at their code and let's hack it together OKAY?

SGML's "takeoff" is pretty well established, friend. You would be hard pressed to find a professional, hot-type emulating typesetting system which does not speak SGML. And as a basis for solid, enterprise level document management system, it's fundamental constructs (and by extension XML's) are unparalleled.
...
The balance of your critique is specific to the desktop platforms and Linux in particular, where the demand for professional-quality type layout and DMS are somewhat limited and, as you say, the popularity and quality of the TeX tools have discouraged innovation.

I think it would be fair to say that all of my critique is specific to desktop platforms, and not just to Linux, either. SGML and XML clearly have a role to play in the world of professional publishing and ``enterprise-level document management systems'', and I acknowledged that role up front. But the specific question asked by Cactvs142 dealt with whether he should write his lab reports using DocBook or TEI, which hardly falls into the areas you describe.

In the world of professional publishing, I suspect that you have either proprietary (and expensive!) software to make creating SGML/XML content not much more complex than writing with a standard word processor (I'm thinking of tools such as Frame, or newspaper systems that provide the user with a terminal complete with specialized function keys to apply styles, etc.) or professionals who are both well versed in and happy to use the raw interfaces. I imagine the same is true for people who have to work with ``enterprise-level document management systems''.

But working with SGML and XML on desktop systems today means working with their raw forms: what tools there are require users to get intimately involved with the internal structures of the systems -- applying tags by hand in a text editor and running obscure command-line tools to generate usable output.

In the world of the average user (corporate or home), however, even command-line interfaces can be scary. People want (and rightly so) an interface like Word's. Users don't want to (or can't) remember obscure tags; they want to write their memos, letters, essays, or lab reports and have the look the way they want; and to not have to do anything more complicated than click on a few buttons and choose some menu items.

Even in the world of the hacker, the current tools for SGML and XML make it harder to use than it needs to be (for instance, it would be nice if psgml-mode switched to a DocBook mode when the DTD in use is DocBook, with a menu containing DocBook tags).

The only tool I'm aware of for editing XML that looks like it might be heading in the right direction (based on the screenshot alone -- the demo isn't much different, given that it doesn't allow you to actually change a document you're viewing) is Conglomerate, and it isn't even close to being ready for public release. If you know of other user-friendly tools, please tell us -- the tools I see at xml.apache.org are all server-oriented, not authoring tools by any stretch of the imagination, and the same seems to be true after a quick search on freshmeat.

When it comes to separating content from appearance, I'm all for it. I do so with both my HTML and LaTeX code. But if SGML/XML editors are rare, tools for creating and editing the style sheets that govern the appearance of those SGML/XML documents don't even seem to be on the drawing board. (Editing text files doesn't count as a user-friendly interface.)

Finally, as for the existence of ``professional, hot-type emulating typesetting systems [that] speak SGML'', it's great that those systems are out there, but just because such systems are available doesn't mean they're universally (or even commonly) used. I'm wrapping up the editing of a book to be published by a fairly well-known technical publisher (a division of a very well-known publisher). The book was written using LaTeX, but the publisher doesn't even want to see PostScript, let alone the LaTeX source; instead, they want the author to print the book out and send them the printed copy. For his last book, the author only had access to a 600 dpi printer, and the quality of the finished book shows that lack. This book will, at least, be printed using a 1200 dpi printer. If a major publishing house is still publishing commercial books in this primitive way, can anyone seriously expect the average business or home user to switch to using SGML or XML for managing far less complex documents?

The URL: http://www.conglomerate.org

Anyone else used this tool yet?

** A side question: Does anyone's company use (or has anyone seen) an in-house manual of style for vague areas of technical documentation (a Chicago Manual of Style for technology). That includes, for instance, context sensitive definitions of data warehouse, ecommerce, business intelligence, etc. All of those great business-savvy catch phrases and buzz words.

Anyone have any suggested references or starting points? **

The main benefit to having everything in XML is that it gives you a standard means of modifying the config files. You could load up anything into, say, Conglomerate, and edit away. (Emacs/vi will work too, although XML is less plaintext-editor friendly). But more importantly, things like linuxconf and your typical next-gen admin tool will finally have a clean, standardized way of parsing and modifying those files, rather than the black magic being used at present. It's much easier to attain that you-can-use-a-text-editor-or-the-gui-tools-equally -well balance with XML, regardless of the number of particular DTD's involved.