Case in point, I tried to write an application once using an early version of DAO with Visual Basic 3. The demo apps ran fine and even the real one seemed OK for a while. But, once I got into the details of error and transaction handling, everything fell apart on me. Now, I had a deadline. I ended up having to write a DAO replacement DLL, which under VB3 wasn't too difficult (easier than COM, by far). About 2 years later, MS updated DAO very much along the lines of what I wrote.
Moral of the story: developer beware. This lesson is a bit deeper than the usual "wait for version 3". The thing is that MS literally doesn't know what the issues are until developers skin their knees on them.
MS XML library - at version 4 - is now among the best in the business. It wasn't usable in production until version 3. Same went for IIS (I still wouldn't expose it to the Internet, but the APIs are stable and performance is good). MS changes their database APIs so often, I wouldn't go near them. Stick w/ ODBC (which started life as the SQL Access Group CLI).
IMO, .NET has problems. Basically, I am judging this by Visual Studio .NET, which is very buggy and a big step backward in functionality. The core engine seems OK, if slow. Besides, who wants to learn C# (a mangled Java)? VB.NET breaks a lot of legacy VB code. Managed C++ is neither. There is no compelling reason to use any of it. Perl, Java and even C++ are all better languages for Web Services development.
So, where does this leave us with Office? Historically, MS Office APIs have been pretty good. It is simple to write a few functions in VBA to open, examine, print, modify and save Word or Excel files. There are a few version dependencies, but the code is by and large transportable from Office 97 to XP.
However, if MS takes as large a departure for Office as it did for Visual Studio, it will be a problem. This is actually relevant. Office 97/2K/XP all use VBA, which is based on VB6/COM. Will Office 11 make the switch to VBA.NET? If so, I would avoid it until at least 2004, if not later. I.e. if your organization makes production use of Office applications, you will have to evaluate and test Office 11 very carefully before proceeding.
Some XML related comments below.
At 10:04 AM 12/20/2002 -0500, Betty Harvey wrote:
I think you hit it on the head. If MS did it right w/ XSL-FO, they wouldn't have to throw away all the formatting info. It would probably reduce file sizes.2. XSLT is used for style within Word 11. You have two options for saving the XML.a. Save as Word XML. This saves the user-defined XML with Word Stylesheet information. I think it would be better if they separated the style from the XML using XSL-FO. WordPerfect does this nicely (with a proprietary stylesheet) and the XML is 'pure'. b. Save as generic XML. This decouples the style and the XML document and is the way you want to transport the document. I got impression that once you exported the XML file you couldn't get the style information back, even with XSLT. This doesn't sound right to me but I asked the question twice.
Option a) jives with Office 2K/XP "Save As HTML", which attempts to support "round trip" editing. Mostly it works, but you do permanently lose things like margins and pagination. I have yet to figure out a way to go back to Word format w/out pasting in text paragraph-by-paragraph.
With option b), then, it makes perfect sense that if you throw away all the formatting data, the only way to get it back is to put it back yourself.
I'll wager that, internally, Word's style handling is fragile. This code base has been through the wars and may be showing its age.
3. It is possible to create invalid XML - this is the biggest
problem that I can see. A user can put text anywhere,
even outside a tag.
4. It looked like there was some 'heavy-duty' applicationDitto. We need XForms married to SOAP. This would give us the equivalent of a browser for submitting chunks of XML content. XDocs might be a first draft of such a product.
development required to make the user-defined XML really
usable by an end-user. This is good news for XML
consultants but bad news for the XML population at large.
5. XDocs was pretty cool. It looked easy to use. They
demonstrated XDocs with a BizTalk back-end. It was
really impressive for application development.
For XML authoring, I would still prefer a native XML editor because it is easier for the end-user. However, for organizations that have Microsoft upgrade licensing agreements it will be a hard sell.
I am hoping over the holidays to install Office 11 (on a computer I am not worried about it interfering with real work) and looking more closely at it.Please keep us posted on your findings. I wouldn't mind being wrong about the stability problems <grin>. Thanks again for giving us the straight dope.
take it easy,
Charlie
--
http://cms-list.org/
trim your replies for good karma.
