Form Filling Through Office 12
Qa32 writes "For those chomping at the bit for more Office 12 details, Microsoft offered a tiny peek at the upcoming offering, or offerings, due next year. In what he termed the first public viewing of Office 12, Chris Caposella, corporate vice president of Microsoft's Information Worker Product Management Group, showed off a distributed forms capability that would enable customers to fill in and submit XML forms easily via a browser, without having to run Microsoft InfoPath on their PC."
InfoPath is one of the programs in one of the Microsoft Office 2003 packages. It allows XML form creation and editing; you can create forms that people could fill out online.
Debugging? Klingons do not debug. Bugs are good for building character in the user.
If you develop custom apps, you might like their current XML export capabilities. It might simplify report generation in a MS-only environment.
So, is it worth it? I wouldn't say so. I notice some new features, I happen to like most of them, but Office XP compared to Office 2000 felt like much less improvement than WinXP to Win2000 (and we all know how much/little that is). On the other hand, I'm generally working in Word and Excel. I think Outlook's evolved more (it's not the same thing as Outlook Express, you know), especially regarding security. Also, when I do need to crank out slides in PowerPoint, I try to make sure that I have a recent version around, since I'm much more comfortable with the UI for entering personal notes together with the slides there. But, on the whole, it's mostly details...
InfoPath works independently from XForms, although the aim is similar, to convert user input to XML. Companies that have deployed Office 2003+ would most likely use InfoPath. Companies that haven't would most likely implement XForms.
PDFs are not widely editable and cannot be used as templates. The whole purpose of this, if you ever have had to fill out forms in document templates, is to easily port information into editable documents. Centralized data input to be dispersed in an automated fashion throughout a larger document, where manual input would be less efficient.
In the business world, PDFs are used for non-editable documents. Specs, Purchase Orders, Invoices, etc. However Acrobat makes for a relatively featureless word processor, so it does not make sense to use it for much else.
Before this was not streamlined into Word (which I remind you is a word processor) without the assistance of either Infopath or custom programmed VB Macros. Now Microsoft has modularized the design further into XML files so that you can now pass form data easily via XML files and then integrate them into documents quickly and efficiently.
If you lose your pre-canned disdain for microsoft and actually bother to think about the technology, you'd see its actually quite useful and has not been accomplished yet by other applications.
I am reasonably certain you can already do this in with Acrobat with the addition of a small cgi script. Look here, scroll down to where it talks about the "FDF toolkit" API.
In order to do this of course you must write your own cgi frontend, so you could say this isn't as much as Office would hypothetically give you. However all Office would be hypothetically giving you here is a prepared drop-in CGI script, and I'm relatively certain were there need for such a thing there would be several free prepared drop-in CGI scripts for doing this with Acrobat already; and certainly it would likely be quicker and cheaper for any organization with access to at least one programmer to write such a thing internally than to wait for, then upgrade to, a new version of MS-Office.
I would imagine however that no one would ever really bother with such a thing, however, since, well, pretty much everyone in the world except Microsoft considers a PDF viewer a necessary part of a modern desktop system and web browser, so few people would particularly think of "requires PDF support" as "requiring plugin"...
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
If you consider XML and using SOAP/Webservices as proprietary, then yes it is vendor lockdown.
Have you ever been to a turkish prison?
InfoPath is a product which allows you to create XML documents which you can email to each other. These documents act like HTML forms when opened in the InfoPath environment. Users can then fill out the form and the data gets posted somewhere like to a webservice.
My opinion is that it is basically like a form on a web page, except less functional, and harder to develop. MS has taken the easiest part of web development (making forms out of INPUT tags) and made it much harder by wrapping a WYSIWYG editor around it. This is yet another attempt to allow the unwashed masses to design their own web forms for data manipulation. I think it is a massive failure so far since it only addresses the most trivial part of web development. And I'm no MS hater.
They are just copying what OpenOffice.org is doing - representing the document as a set of XML files, and compressing them all into a single ZIP archive.
As it is, it is a separate environment, and as far as I can tell you can't embed an Infopath document within a Word document.
:-)
That's really... strange. In PDF forms you have editable fields which can either be saved in the document, or (if you add a submit button to the document) submitted back to a server. You can also store the data in an FDF file which contains a link back to the PDF. When you open the FDF, Acrobat downloads the PDF and populates it with the FDF data.
It sounds like Microsoft isn't even that far.
Javascript + Nintendo DSi = DSiCade