Scott, thanks for the thoughts on the posts! Being an MS developer, I really enjoy reading the blogs. That said, we'll have to agree to disagree on the WordML thing...

<rant>
Depends on your goal. I have to agree, that if all things were equal, an XML format would be the way to go. All things, however, are not equal. If your goal is for the user to be able to open the file, than RTF is still your best bet (or PDF). As of today, I believe only one program can digest that file, Word 2003. (And I believe only the pro version at that!) MS needs to dump the binary format and switch to XML as the default moving forward if they want this format to gain any traction. Even then, it will take years before one can assume a program can digest it. Of course, MS will have to deal with the fact that this will make it easier for anyone to read their format. (Isn't that the goal, though? It's not like it is IMPOSSIBLE for competitors to read a DOC file, it's just difficult. Short of encryption, your not going to succeed on format lock in anyway.)

Now that I'm totaly off topic, I wonder why (like almost all other vendors), MS doesn't support PDF generation in it's products. Hmmmm. You may agree or disagree that it is technicaly the best format, but whether anyone likes it or not, it is THE standard. Well, WMP10 now FINALLY fully supports MP3s, FrontPage 2003 (for the most part) generates good, cross browser HTML code...maybe MS has seen the light.

MS makes some great stuff, if only they had better support for standards (wether or not it is their standard), more people would use and be happy with their products. The temptation for alternatives would diminish rapidly, and some of these Linux zealots would calm down.
</rant>

I also find that HTML is often a good format for documents that simply need to be printed. It's certainly easier to embed images than in RTF or even WordML.

Hiya,

good to see that you are back, John. Hope you're feeling better.

We are basically at the same point. WordProcessingML or ...? I looked a lot into "...ML" in Word. I must say I agree with you about XML. But: XML is not WordProcessingML! Unfortunately this gets always mixed up and I fear that in your post it is also not very clear. I agree with what you say about XML, I disagree if you want to apply this to WordProcessingML (have you ever looked at the WordProcessingML for a List? Why the heck used MS a flat structure for a Structured Format if XML is a structured language?).

We currently use VB6 and Word Automation using Bookmarks. We are doing the next step thingy into .Net and (hopefully) Word 2003. Our Vision was: use XML Data, join it with a XSLT and voila you get a Word Document. Unfortunately its not that easy. We can't expect the user to create XSLT. Using XSLT we are limited to HTML Formatting etc.

For me the ideal world would look like this:
The user creates Word Docs, drag and drops XML elements into his text, sourrounds paragraphs with XML Nodes to switch them on/off, saves the whole lot into a Repository as a Stylesheet (as he/she currently does using a Word Template) and our Application uses this Stylesheet with XML Data to poduce a Word Doc.

I must admit RTF came to my mind. We use it in some parts of our organisation and it works fine.

I got the feeling that the WordProcessingML just uses the existing Document Structure and ports it to a XML Style format. Its a bit more readable than RTF but I can't see it very re-usable.

But that's just my opinion.

Cheers

Peter

John,
thanks for your additional posts.

I do like the WordML stuff and we are exactly working on a solution outlined in your picture.
we have a java app server needing to communicate with end users. On the java appserver we generate WordML docs (no word involved) and let the user modify them using Word and then upload them back to the server for further processing.

to a certain extent this is very nice.

One point with regard to using Word on the server... sometimes for example you want to use the exact feature from Word like merging/diffing and then even from java you need to invoke word on the server to exactly mimic what a user would see if he/she had done it him/herself using word. Sure this can be programmed exactly alike, but why re-invent the wheel?

With regard to WordML / Smartdocuments, in my experience there is something in between using the XML Schema validation that is in Word (I think I commented on this before). There does not seam to be an easy way of linking the schema to the respective document... If you could shed some light on that I would appreciate it.

Keep on Blogging!!!!

Michael

Gabe et al,
I agree with some of your thoughts. I agree that PDF has its merits. You can in fact, via document protection and so forth, approximate the experience in Word, but it is not quite the same. On the other hand, I find the Adobe reader klunky and limiting. Also, the extensibility story there is not exactly transparent let's just say.

You can read my thoughts on standards and the difference between XML and WordML on my post for today (October 29).

I also agree that the XML markup for some things in a Word doc can get rather verbose.

In my view, the market for 3rd party tools and utilities to do things with Word and its XML file format is mostly untapped. If I did not work for Microsoft and was putting on my entrepreneurial hat I would focus in that area. Some of the very ideas you have advanced in your feedback could be great ISV opportunities. To me, this is not evidence of a weakness in Word 2003, it is a testament to its value and extensibility.

Fundamentally speaking, PDF is designed for print formatting (though I'm sure that's not the right term). That is to say, it's nice for making text look picture-perfect for printing. That's not necessarily what you're shooting for when serving up documents.

For instance, an application a client uses for serving up documents is a large MSSQL-based library of PDF files (stored in image columns, with Full-Text indexing via Adobe IFilters). (I'll agree with you right now if you say that's stupid and they should be in the filesystem, but hey, it works for now.)

An annoying problem with this approach, which several users of this application have complained about, is that even after a full-text search locates a document, you can't look *into* it. No decent-looking search previews, and there's no mechanism we can figure out to highlight search terms in the loaded PDF. If they locate a phrase they want in a 500-page PDF, they have to open the entire PDF and *then* do a Find in that document for their phrase.

So one idea... had been to maintain some sort of metadata-laden version of the document in XML, and another version in PDF. Except... the dual-maintenance of documents would be unwieldy. Either we'd have to use a tool to deconvert the PDF into XML (with all the incipient errors like hyphenation at EOL, etc) and manually add extra metadata, or we'd write it in XML and have to find a way to generate a PDF.

Now, with WordML? We can maintain it in Word+XML, add in custom schema metadata, use an XSLT to convert that into HTML for easy per-page browsing with highlighted search terms, print the Word document into PDF via Distiller, and generally have a single point of maintenance. And heck, we can Protect the document (not like there's a lot of security there, hah!) and even serve that up on the website.

As John said, sure, it's not a perfect feature that everyone will bend over backwards to support and accept. But hey, it's a step in the right direction, and I don't see how it's a *bad* step, just not necessarily as good now as it *will be* in years to come.

PingBack from http://hairgrowthproducts.info/story.php?id=1126

PingBack from http://debtsolutionsnow.info/story.php?id=3309