XDocs and the age of new XStars ( X* ?)
Last week Microsoft executive started talking about XDocs. Here is Microsoft’s description. “XDocs,” a code name for the newest member of the Microsoft Office family, streamlines the process of gathering information by enabling teams and organizations to easily create and work with rich, dynamic forms. . A few usage scenarios on this page talk about some sample applications.
Here is my wishlist for XDocs or similar technology.
XDocs web component ( an .net component, activex control, java applet or some similar web object). This will allow me to insert an XDoc anywhere in a webpage. This means, all the website interactions with the visitors will be based on custom schemas and will have better semantics.
XDocs Office Component. Imagine the ability to click on File/New in Microsoft Word and see a bunch of XDoc style sheets. When I pick one, it looks like a Word document with sections. For example, as a marketing dude, I choose a document called Customer Visit. This document contains sections where I can type customer contact information, feature requests, reactions to prototypes I presented etc. Once I enter this document, different parts of the documents are streamed as XML to different applications. For example, the feature requests may be automatically inserted in a product database.
XDocs mail component. Somewhat similar to the scenario above, except that when I Compose/Create a new mail, I get to pick one of the pre-defined formats (each one based on an XDocs format). Let us say that it is a simple meeting request. When I send it out, it goes to my colleague. When my colleague opens the mail he is prompted to Accept/Reject/Request Postponement. The last option appears only if he has a conflict in his calendar (magically performed by an plug-in in the email client which can process XML). I know that this stuff works in outlook. But I would like it work in yahoo, hotmail or any other mail system or webmail client. When my colleague clicks Accept, his calendar is updated automatically. A development kit to allow me to define my own sequence of actions for each type of mail I receive would make it even more extensible.
Let us assume that have a new collaborative environment called XGroups based on XDocs as the underlying format. It has the ability to create your own message types. If I want to compose a plain old message, I simply pick normal as the type and I get the conventional email style message. But think of what can happen in this group. This is an extensible infrastructure. Let us decide that our XGroups decide to share a bunch of bookmarks. We simply design an XDoc called Bookmark. When I compose a message, I pick Bookmark style and simply enter a web page address. As a product team, we may decide to have message type called Feature Request. Everytime someone enters a feature request, it looks a like a normal message but is automatically tagged with the product name, the source of the request (customer, internal etc) and the request text. As we interact using XGroups, we are building a knowledge base behind the scenes.
What will have next? XMail (XML based email), XMTP ( like SMTP except it is structured with XML messages), XTTP ( like HTTP but will get/send xml streams for apps). With all this we may really need an XVM (an XML virtual machine).