Well it is a new year, and I am still two-parts away from getting my ‘5-points’ series done. In an effort to start the year with a clean slate, I’ll try and get the last two polished off quickly.
Everything we are doing around XPS is about building a platform for others to create amazing solutions for their customers. That really is ‘Job One’ for people working in the Windows group. All this stuff we build is useless if we don’t enable our IHVs and ISVs to build better products, create new solutions for their customers and do it faster and cheaper by leveraging the XPS file format and the Windows platform.
People will naturally focus on XPS being a document format and debating whether it is better or worse than PDF, TIFF or any other format that is used to represent graphical content. That’s expected, but I think people really miss the point about what we are trying to do. We are not just trying to build a file format and an end-to-end solution around it. We are trying to build a platform and the file format is just one part of that platform. We want developers not to have to invent their own way to represent content on a page, their own way to package up the content and their own way to sign or rights-manage the content in order to create rich document experiences for their customers. They should be able to leverage these services in the platform and focus their R&D on solving key customer problems.
I think of our platform in the following ways:
Helping print hardware vendors build better and faster color printing solutions for their customers
o Increasing their ability to innovate in the print pipeline by fully describing and opening up the spool format
o Providing an graphics architecture that allows the applications and the print pipeline, all the way to the device, to use the same graphics format
Helping ISVs build secure document publishing into their customer solutions (regular end-user apps, LOB solutions, workflow, etc)
o WPF APIs to create, navigate, update XPS documents
o WPF APIs to digitally-sign XPS documents
o WPF APIs to publish/print XPS documents
o WPF APIs to rights-manage OPC documents including XPS and Office "12"
Enabling anybody to build solutions from the ground up, on any platform, using XPS or Open Packaging Conventions specifications natively.
Make sure you read the MSDN article Programming XPS Documents if you want to get a quick overview of the APIs in WPF for XPS.
Don’t underestimate the value of having a simple, clean format the represents rich raster/vector graphical content that is open and easily programmable built into Windows. This will enable lots of scenarios that were simply too hard to get done in the current Windows graphics architecture. XPS, for instance, will enable higher quality documents of ‘any format’ to be published from Windows. Since the generation of most file formats (like PDF for instance) are generated using the Windows Printing Subsystem, the enhancements we have made by utilizing XPS in the print pipeline will enable better quality graphically content in the print pipeline that can then be converted to anything else. This really is a ‘float all boats’ sort of story.
There is also another part of the platform that we have not talked much about . Since it just came in the November CTP of WinFX. It is a plug-in interface into WPF that allows anyone to register a file-creator that can take the XAML content represented in an application and directly create any arbitrary file format. With that plug-in, an application can build in way to directly generate any file format – including non-visual information that is not available through a print interface. (Look in the SDK for the System.Windows.Documents.Serialization namespace.)
A last point to support my platform goodness speech. We could easily have created a proprietary file format that did not work cross-platform, we could have build amazing end-user applications and solutions and created a bunch of end-to-end document solution for customers. It probably would not have taken any more resources and certainly would be easier to test. But – genetically, that is not what we do here. We build core technology to enable others to solve customer problems. Building platforms is very hard, and sometimes it is frustrating that we can’t do more, but we know our partners will do a better job than we could. Now of course we do build some user-experience. We are focusing on the simple scenario of enable a user who wants to print and/or share documents safely and securely, the simple ability to do that. But my estimate is that less than 10% of the team is building that out - the rest of the team is working on the file format and the platform APIs.
I feel like I’m doing a lot of selling in my ‘5-points of light’ series here. That certainly is part of my intention – we have something new, I want people to understand its benefits. But really, my goal as I stated at the start is to give people the bigger picture. It’s not just a file format, it’s a whole platform. It is also not just the platform from the point of view of a bunch of APIs, it is also the way we have integrated the technology into the platform – that is the teaser for my next and last entry.
Part 5 will be called: Integrated Solution