XPS Five Points of Light – Part 5: Integrated Solution


Integrated solution – well that certainly brings up some interesting thoughts. Integrated-innovation is something we talk a lot about at Microsoft, but delivering on it is not that easy. The XPS project was started with some very lofty goals to be built as part of an integrated solution and integrated technology. Now, I’m not talking about integration from the point of view where some slimy software sales guy tells you "We have an integrated solution designed to deliver to you lower costs and more profits! You are interested in increasing profits aren’t you??" No, but please come back next year when I have a $3 million dollar budget to piss away on a long term, marginal-value software project for my company. I digress…


Sometimes people say ‘integrated’ and what they really are talking about is bundling a bunch of software together that has some level of forced interoperability. What I’m talking about is building a platform where the software pieces that make up that platform inherently work better together, so that the value of the platform is greater than the sum of its components. Or, specifically that integration at the platform level means building features that work better together by virtue of sharing the same underlying technology. Essentially – you force a large distributed software team to not re-invent the entire software stack from top to bottom to deliver one new feature to a customer. You ask them to recognize the multiplier-effect on customer value when that software is built with integrated principals from the beginning.


Here is what XPS and integration means:


Using Open Packaging Conventions. Why? So that the same software that needs to open up and manipulate an XPS document, could also be used to do the same thing on an Office "12" document or any other file that uses Open Packaging Conventions. So that an XPS document could be rights-managed by Windows RMS automatically – no extra code to write (but still cleanly separated so any other RM solution can be used.) Was it hard? You bet, would have been a lot easier for us to go our own way, invent or use something else and we could innovate quicker and ship quicker. But making the bet, delivering on customer value that is bigger and more impactful than just our own world with XPS, is worth it. Few companies think this way, and I’m glad we are on of the few. Hopefully, maybe 5-10 years from now, every single application and file format uses Open Packaging Conventions and the pure value of interop that gets delivered to customers is huge.


Same Markup as XAML


This was a tough one also. XAML is an application markup language – quite an amazing and powerful one in fact. We knew that one of the core issues in persisting documents and printing documents is that the symatics in which the application describes graphics is vastly different than what gets persisted down-stream during publishing. We fundamentally wanted to change that. To do so, we made the decision to make the XPS markup a subset of the XAML markup. Now this makes it really easy to persist the high-quality graphics that XAML can represent all the way through any publishing activity (screen/print/archive). But, in addition to the publishing scenarios, just think of getting an XPS document and wanting to use the base markup as foundation for creating an interactive Web experience , or just steal some markup to use in a WPF application. It is as simple as cut and paste. These are important scenarios for our customers, but delivery is very hard. You can imagine that the architects of XPS grew sick of bi-weekly changes in the XAML design that had adverse effects on the XPS markup. At some point you think – is this all worth it? Why don’t we just create a unique markup for XPS so we can innovate faster and ship quicker (notice the theme). Well, building platforms is hard work and building platforms with an eye on good integration is even harder. In then end our partners in particular will be happier we took the effort to climb the bigger mountain on this one.


Document Format same as the Print Spool Format


Here is another tough one. Document people would love to build a new file format that represents an electronic document and not have to worry about the requirements of printing. Not have to worry about the ability to stream the document over the wire to a printer, or that it should be small and compact so that it could be rendered in firmware. Print people would like to not have to worry about things like digital signatures, document structure, annotations, rights-management. They want only the things that matter to getting dirty-marks on pulp. In fact – why can’t every document be interleaved from the beginning (meaning, that the resources for each page are at the same place in the file as the page itself) so it will print faster? You can see the design tension here. It bleeds into the way fonts are handled, the way the structure of the document is put together. It was a fun battle to strive for non-compromising integrated design (hmm..seems like a title to a book or something). I think we have hit pretty close to the mark on this. We have print scenarios that will be better than anything Windows has ever delivered and document scenarios that enable simple, easy and secure sharing of documents on any platform. Best of both worlds.


OK, so I’m crying like a baby: Waaaaah…building platforms is hard! Waaaah …integration is hard!. Just suck it up and do your job Simonds! I hear you – we will ship. We will ship this year, I promise.


No Part 6 – this is the end.


- Andy


Skip to main content