OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MS Word as XML editor?

I have been listening to this debate for quite some time and have a vested interest as my company makes a product that does "up convert" MS-Office documents to well formed XML.

As I understand it, you have created applications that allows the capture of a
certain class of documents only though. If you wanted to create different documents
tomorrow, you would have to program again, wouldn't you? The original poster asked
about "using MS Word as XML editor (ideally like FrameMaker+SGML)" - that's not
really what you're doing, is it? You rely on being able to predict (or discard)
structure, whereas FM+SGML will XML-ise any structured or word processed document.
While you make a very good point, the reality is that the cost of retraining millions of MS-Office users to use powerful XML Editors is enormous.  But the benefits of getting content into XML for reuse is huge.  It can save organizations tons of money by reducing manual cutting and pasting and errors in re-entering.  What is wrong if we can get a large part of the way there by using domain specific constraints and then installing a less laborious and less cumbersome process of "cleaning up markup errors".  You can not argue that it does not have value although it may not be perfect?  As for the programming for different types of documents, one way to address it is XSLT and a good XSLT development tool.

Sure, but the impementation must surely be at least partly constrained by the
existing application. The point that I was making was that it is not easy to layer
structure on an application that was not designed for it, even if you own the
source code for the existing application.

I agree with you here.  Even if you have access to the Object Model for the Office documents, it does not lend itself very easily to complicated nested markup.  We had to spend countless programming hours to come up with fairly robust and reasonable solution to this problem.  It is not perfect but stacks up well against the 80-20 rule.

But then I am biased.