Slashdot Mirror

[plaudits for XML Spy by several posters]

I don't see how average office worker could ever do anything with XSL(T)

I'm only half joking: If people are bothering registering to get emailed a username/password that activates a 30 day trial, then they're probably re-activating something they installed months back, like say XML Spy, and with an infinite number of email addresses....

Other points in the article that scream XML to me:

* A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, etc.), options, category (for subsections within the config), and help text (short and long).

This looks very much like XML Schema to me - it can specify all these data types, including enumerations, and a schema-aware XML editor (eg XML Spy in the Wondows world - anyone know the best Linux option?) will prompt you with help-lists of valid elements and attributes, or list of enumerated values. Doesn't do help text by default, but has an expansion mechanism (xsd:appinfo) for adding application-specific to be added to a schema.

* It all needs to be language, distribution, and operating system neutral, so as to avoid turning off any potential software developers who might find it useful.

I don't know of any programming language or O/S that doesn't have an XML Parser (many don't yet have XML Schema support, but if you stay off specifying default values you don't need that at run time). And XML is good for natural languages - UTF 8 or UTF 16 from start.

There aren't many formats that are equally machine and human readable, even fewer that allow document struture and data typing, and still fewer that have open or free implementations on practically all platforms.

IMO, I think it's important to be comfortable with more than one "type" of IDE when writing Java code. The sophisticated Java IDE's are often very slow to startup, especially if they are written in Java itself (e.g. JBuilder, Forte take upwards of 20 seconds to startup on my machine sometimes - JDK1.3, 512 MB, 400 MHz) which can be a pain in the arse for impulse coding or quick changes to code when the IDE is not running.

Therefore I've found it helpful to have two IDE's I'm comfortable with:

1) A stripped down, quick and dirty text editor which allows you to get in and out of files quick (e.g. notepad, ultraedit under Windows, whatever)

2) A whizz bang do everything for you IDE which provides a huge amount of features (Wizards, code management, plugins) like JBuilder, IBM VisualAge for Java, Forte, Oracle JDeveloper etc etc

See the following links for full lists of Java IDEs out there:

http://www.javaworld.com/javaworld/tools/jw-tools- ide.html

http://www.webdeveloper.com/java/java_ides.html

Personally I've used about 10-15 editors tailored for Java and enjoy using Borland JBuilder5 (Enterprise) at the moment for the following reasons:

Wizards for just about any Java component you would want to create - Servlets/JSPs/EJBs/CORBA/Javabeans/XML. This avoids writing a lot of tedious code.

The ability to code all parts of a Java web app. with proper syntax highlighting, and code completion etc. in the one IDE (HTML, Servlets, JSPs, EJBs). The ability to preview the web. app. in the IDE without starting up the app. server. etc, can be helpful (JBuilder comes bundled with Tomcat (and Cocoon), supports Websphere, Weblogic, Borland Appserver and other plugins).

Code completion and insight - Java has lotsOfLongMethodNamesWhichAreSometimesABitTooDescr iptive and a pain to type

Rapid GUI prototyping (null, XYLayout) for Swing clients (if anyone still builds Swing clients, just joking ;-))

XML support, Cocoon, XML to DTD, DTD to XML, XSLT transformation previews. You'll may need something like XmlSpy for more sophisticated XML development however.

Full customisation of pretty much any part of the IDE, keymappings, toolbars etc - I like to use my own keymappings.

Having all parts of a Java component (e.g. methods, attributes) accessible by clicking on its name in a GUI IDE panel - this can be nice to locate sections of code when a Java class becomes large.

I could go on and on, the full feature matrix is here. Of course JBuilder Enterprise costs a *lot of money* and I probably would'nt buy it for home use.

One problem, I refuse to work on JBuilder with less than 512MB RAM. It's written entirely in Java and although they do a great job to make it as fast as it is (using custom class loaders I've read somewhere), stuff like code insight and code completion is painful with anything less than 512MB RAM.

You may want to take a look at XML Spy as an XML Editor. It's a commercial product (about $199), but I've used it to build a DocBook file, and then used the DocBook XSLT scripts to generate HTML. I've also used it to generate custom DTDs, which worked pretty well. The product can import Word files (converts Word Styles to element types). What they really need is an XSL script to generate Word formatted files. That would be great! I'm not sure your basic office folks are quite ready for it, but with a little training, they might be weaned off of Word.

At my company (in fact it's a local branch of an US based corporation) we have similar problem. There is a team here developing a system designed specifically for a customer. As one can expect along with such a system goes all the documentation - everything you could expect starting from the analysis, through functional specification and coding guidelines to end user and administrator's manuals. To make things more complicated part of the development - and the documentation - is being done by a subcontractor (which happens to be on another hemisphere) - and it is being prepared in English, but some parts of it (especially the manuals) have to be translated into local language.

Up until now it has been a growing mess with documentation being written in Word (with all the usual problems Word has with large files, with lots of graphics - screens, no versioning etc.), with no standards, with people getting into one another's way while trying to update the numerous documents.

Recently together with a friend we have came up with the idea to switch all that into neat XML/SGML files, with CVS based versioning and everything based on open standards and free software as much as possible. To our surprise the management liked the idea and we got a green light to do some research. And then the problems have begun.

First, the editor. Coding XML files with vi or alike might be nice for a hacker - and is great for creating and testing XML formats used then for data storage etc. - but it is out of the question for documentation authors. And it is pretty understandable - to be able to concentrate on the content, on the text itself, the author needs to see only the contents, as nicely rendered as possible - no tags getting into way in each sentence, no learning for years how to use the editor (thus Emacs with its psgml mode is not an option - don't flame me, it's just a fact). After a long search I have to say that there is no working, finished GNU/free editor that would match our requirement of almost-WYWSIG presentation of an XML/SGML file. As to commercial ones the only two that look good are XML Spy 4.0 - but it is just a poorely working beta for now - and Arbortext's Epic - which is almost exactly what we need, but is a bit expensive at around $700 a license.

Nevertheless, with no other options left we decided to go for the Epic when it comes to the editing side. We got an evaluation package and begun testing.

Now, we were from the start convinced that DocBook DTD & tools that go along with it are the best choice for the kind of problem we faced. Epic supports the DocBook but comes along with their own version, which in turns doesn't work well with the Linux sgml tools that we use for translating the XML/SGML files to useful end formats. On the other hand not all Epic's features can be used when one just tries to edit the document based on an "external" DTD. To enable things like being able to see the graphics files inserted into the document one has to hm... "customize" the Epic by creating some additional configuration files (like .FOS files) using yet another expensive tool Arbortext sells - the Epic Architect.

But that is not the end of the problem, because the stylesheets currently available for translating the Docbook based XML/SGML files into useful formats are not well documented and partially don't work (for example tags related to inserting pictures in the document are ignored when trying to generate a printable document). There is for example a project on Sourceforge that develops XSLTs and DSSSLs for translating Docbook based XML into various formats, but so far I was not able to make them work - and there is no documentation. Also the DSSSL based machinery for translating SGML files that comes with various Linux distros is far from perfect - HTMLs are generated mostly OK, but printed documents (.tex and .pdf) leave much to be desired.

So, from our point of view it looks like we will have to buy an expensive editor and then someone would have to spend a month or so tweaking the editor, modifying the stylesheets for our needs, developing procedures and so on. And that someone would have to be quite a competent person (with deep knowledge of the subject), someone, who could be probably better used directly in the development project.

As for now the future of our little plan of switching from mess to neat XML based solution is uncertain. Mainly because we would have to build that neat solution ourselves, as what we can get from outside at the moment are some bits and pieces that - although nice by themselves - just don't fit together.

(And, BTW, I haven't even touched the nice catch with CVS - to be really useful in the kind of environment that we envisioned it would have to be integrated with the editor - and that doesn't seem likely).

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.)

As a sidenote I recommend that anyone not quite sure about XML/Schemas check out XMLSpy (Disclaimer: I don't work for that company, nor do I know anyone who does. I just think it's a very nice program for getting practical experience relating to XSD schemas, etc.).

I started using it for XML editing, and it's turned out to be a decent HTML editor for me. Still just a text editor, but with validation on save, close tag insertion when you enter a tag, and some other niceties.

Tim's point about Kapor and Lotus 1-2-3 is very salient and timely. Think about it. Linux has reached a point where it threatens commercial products like NT for market space, forces OSS business models into the mainstream, pressures closed-source vendors to provide products for Linux (even if they don't want to participate in the OSS process), and generally returned a great deal of industry power to the hands of the consumer. The computing community is clearly ready for the next step -- the OSS killer app phase.

What is the killer app? Apache? Samba? There's no obvious answer, and Tim touches on this with his discussion of HTML. But he's still a little hung-up on the "web-based infoware" thing. I think the killer app that we're all waiting for isn't an app at all. The Linux/GNU/OSS movement has caused major shifts in the philosophical as well as computing landscape. The killer "app" is really the arrival of portable data. We've so commoditized the applications that it doesn't matter whether you're using Word, Wordperfect, Staroffice, Claris, a web-app, or who-knows-what else. What matters is how difficult it is to share information. Most productivity app vendors have decided to mimic MS Office 97 formats by providing converters, allowing in-format editing of MS-format documents, or using HTML as a native format, but these are only stopgaps. The next hurdle is to apply the OSS philosophy to content (data formats, interchage standards, protocols, translations), not just structure (operating systems, apps, web apps).

We're starting to see this a little, and it seems to be following XML. GNOME spreadsheets are stored in an XML format. User-friendly XML text editors such as XMetal and XML Spy are starting to show up for Windows. Oracle is starting to provide mainstream support for XML-based EDI. Consciously or not, we're beginning to think of common content formats as a global necessity. The problem, of course, is that these standards are typically built by glacially-slow concensus in a private industry forum. For example, the DTD for telecom information interchange that I was briefly involved with is maintained by the Information Products Interchange (IPI) subcommittee of the Telecommunications Industry Forum (TCIF), which is a subcommittee of the Alliance for Telecommunications Industry Solutions (ATIS). [See http://www.atis.org]

Buried in such a hierarchy, it's a wonder that the IPI's Telecommunications Interchange Markup standard (TIM, an XML-compliant SGML DTD) evolved at all. It's success is due primarily to the efforts of a few dedicated individuals. Sound familiar? This parallels the way that Linus et al manage updates to Linux kernel code. We're used to thinking of open source in terms of Linux and GNU software. Tim thinks of it as inclusive of web apps touches on interchange. We need to open that up to specifically include content. If you'll forgive the analogy, I think we've covered the nouns, and we have to think about the verbs -- apply OSS to the things we DO and not just the tools we use or places to do them. Open source organizational clearinghouses and listservs need to start providing for open source development of data formats and standards, not just apps. (Not to say that anyone working on OSS XML tools for Linux should slow down in the slightest!)

Those of us interested in data interchange, which includes anyone who ever shares so much as a text file, need to organize and communicate. If there's no standard for your data, develop one. If there is, contribute, review, and use it. (Think about harnessing all the wasted effort consumed by MS Office file format woes!) Don't let a vendor hold your data hostage in a proprietary format. The momentum behind Linux and other GNU software is driven by quality of the code and openness. Apply that to content, and the world will become a much better place.

Jon