XPS: One format to rule them all (or maybe not)

One format or multiple formats?

Some would have you believe that one format does everything everyone will ever need. Some feel that, by extension, two similar formats, or two formats that have some degree of overlap, must be 'competitive' (or designed to be so) because "one format is all you need". On the other side of the fence is a viewpoint that you should use a highly tuned and format that’s optimized for a specific application… sometimes so optimized that it's a pain for anyone else to use.

I happen to fall into a more pragmatic group: try and use the best format for the job where ‘best’ is a combination of things like features, performance, interoperability, cost, ubiquity etc.

So where does XPS fit? XPS is designed to be an excellent format for electronic paper. It’s also designed not to address the wider requirements for electronic documents. There’s some good reasons why that design intent makes sense, and I’ll dig into some of them in this post.

What does XPS address?

As I said, XPS is designed to be an excellent format for electronic paper. By electronic paper we mean a digital representation of the content that you can print to, or scan from, physical paper. XPS supports the graphical primitives necessary for a great reproduction of paper content – basic stuff like graphics, text and images. But the way XPS supports these primitives is extremely robust. If you print something on physical paper you have everything you need to view the content (you don't need to go and find the fonts in a different drawer in your filing cabinet for example). XPS does something similar, all the resources needed to render the document are contained within the document.

What doesn’t XPS address?

By definition, if XPS is designed to support electronic paper, there’s a whole slew of capabilities that it doesn’t support. These include flashy things like animation, video, audio, dynamic content, scripting or macros. Interestingly, many people think that XPS needs to include these capabilities to be ‘competitive’. The problem with that is it assumes XPS is designed to compete with something that has those capabilities. It also misses the strengths that not supporting more features can provide.

Less is More

So how can supporting less features make XPS more valuable? Well, here's a few...

• XPS includes only what you can print. This is a critical feature. By not including capabilities that can’t be printed, XPS ensures consistency between soft display and hard copy output. It also avoids potential temporal differences from including animation, video or other forms of dynamic content and thereby provides a greater level of trust between different viewers.
• Implementation cost. By limiting the feature set XPS limits the implementation cost. This has two big benefits. Firstly, low cost of implementation promotes interoperability, encouraging a ecosystem of software and devices and ensures that users are not locked into a single vendors products. In the case of XPS, it also makes it possible for people to easily roll their own solutions. Secondly, low implementation cost significantly increases the quality of implementations. Quality does matter - more on that below.
• Threats. The more features you add the more threats you have to mitigate. As operating systems and web browsers become harden against malicious attacks, the bad people go looking for other widely deployed technologies to try and compromise. Technologies that are designed with content sharing in mind are an obvious target. By limiting the feature set and expressly excluding capabilities that require programmatic code within the format, XPS significantly reduces the threat surface and makes it easier to implement the format securely. This is significant when you consider that document devices are becoming deeply integrated into enterprise networks, while at the same time are becoming more powerful and intelligent.
• Simplicity. Formats that support lots of features often reach a point where people start defining sub-formats to scope the format down to a set of features that work for a certain scenario. Sometimes this is to reduce implementation costs for unnecessary features, sometimes it is because the use of some features would break certain scenarios (as a silly example, if asked to print content encoded as MP3 audio). This becomes a real problem when exposed to end users – you know, the people that have real work to do and who don’t spend all day thinking about document formats and the like :-). With end users multiple sub-formats become very confusing. How do you communicate which sub-format is required? How do users find the tools and configuration options to create the right sub-format? How do you check that you have been sent the right sub-format (and if you’re worried about security, how do you check without having to download it and look inside?). Here’s an example from the world of image formats. If I say send me a JPEG I have a much higher confidence that I’ll get what I expect than if I say ‘send me a TIFF’. You can do much more with a TIFF than a JPEG, but it’s also much easier to construct a valid TIFF that’s not suitable for a particular scenario and ‘Send me a JPEG’ works with far more people than ‘Send me a TIFF with this set of tags but don’t use any of these tags’.
• Electronic paper workflows work. XPS is a bridge format between electronic paper and physical paper (using the analogy of freeways in the USA, it provides the on-ramp and off-ramp). By their nature, workflows that span physical and electronic paper work best when document peripherals (scanners, printers, fax devices etc.) are included. XPS enables those types of devices to participate in workflows as first class citizens and, by not including lots of features that are irrelevant for these kinds of workflows, ensures and high quality and consistent experience irrespective of device type or capabilities.

Implementation cost really matters

Implementation cost is a significant factor in quality. Lower cost means higher quality (or at least it typically does ;-). High quality implementations have numerous benefits, but here’s a couple of the less obvious ones to ponder…

• Threat Surface. XPS, by design, reduces the threat surface, but you still need to appropriately protect that smaller threat surface that remains. Writing secure code is not trivial (although there are resources to help) and having a low implementation cost helps drive quality and security by enabling developers to spend more time implementing robust solutions. Further, having a simple format makes implementations less complex and therefore easier to secure.
• Compliance and Compatibility. The more stuff there is to implement, the harder it is to get the implementation right (that applies both when you're following a specification, or specifying what you did). Mistakes happen, that's just software (and life). The problem is, mistakes mean implementations that don't meet the specification 100%. When that happens, and assuming you care about interoperability, you start having to worry about compatibility between different implementations as well as compliance with a specification. All other things being equal, having less to implement means the delta between compatibility and compliance is minimized (ideally, it's zero) which makes everyone happy. (and at this point it's worth noting that Microsoft implementations aren't always perfect, and neither are most when you look closely, so either this stuff is hard, or...)

But I want features that aren’t in XPS...

...great, there are plenty of excellent formats you can use instead. That's the point! Look at the tool box and choose the right tool (or the tool that compromises least) for the job in hand.

The exceptions

There’s always exceptions right? When I look at XPS today, and the goals of electronic paper, there are some things that are missing and that, personally, I hope get addressed at some point in the future. But they're all things that make sense within the scope of electronic paper so, that said, you can probably guess what they are…

Comments

• Anonymous
  August 02, 2008
  PDF/A - sorry for the typo !http://en.wikipedia.org/wiki/PDF/A
• Anonymous
  August 13, 2008
  Thanks Michael, PDF/A is a great example of the need to downscope a format that's grown to address a broad set of scenarios.The identification section in the wikipedia article also hints at the point I was making with this comment "How do you check that you have been sent the right sub-format (and if you’re worried about security, how do you check without having to download it and look inside?)."
• Anonymous
  February 07, 2009
  Hello Michael,With regard to the point Adrian is making, what would you say would be necessary in order that everyday endusers in the EU and the US be able to save softcopy that preserves invertibility for character content as well as for colour content?From a fair amount of teaching experience, almost all of it available online, I would say that trying to teach distinctions between ISO sub-standards when everyday endusers neither distinguish between characters and glyphs nor between colours and colourants is a loosing game.There is, furthermore, the matter of ISO sub-standards for character-glyph mapping. Adobe notes that the Adobe Type 1 library is ISO 9541 and the Adobe OpenType library is ISO/IEC 14496-22, but do these ISO sub-standards say that overruling the character set in drawing is technically incorrect? The underlying issue is that the Adobe imaging model introduced in 1985 is based on a configurable name space model and not on a coded character set model. The configurable name space model was used to overrule public characters in Apple Roman in the first phase of the commercial conflict for the digital document market. John Hudson speculated to James Felici  of Seybold in 2002 when the Adobe OpenType library was launched that Adobe would discontinue its past practice of overruling the coded character set in order to draw glyph alternates, but Adobe did not. At Linotype Typotechnica in April 2007, Thomas Phinney stated that Adobe would continue to make and market Adobe OpenType products that can draw glyph alternates from private 'charactoids' in ISO-IEC 10646/Unicode.Your challenge in championining PDF is first to distinguish PDF from PDF/X and PDF/A, second to distinguish PDF/X sub-standards from PDF/A, and third to distinguish PDF/A sub-standards from PDF/X. Your challenging in championing PDF is furtherore that Adobe's imaging model does not depend on preserving the author's content represented in the standard coded character set intact. The consequence of this is that Adobe is not interested in stating publically that the type products it has made and marketed in hundreds and hundres of millions of copies cannot conceivably be claiimed to comply with the best practices of the intelligent composition model that inserts a protective separation between character processing and glyph processing or with the precept that direct drawing is destructive drawing expressed in ISO-IEC Technical Report 15285, An Operational Model for Characters and Glyphs.It was interesting to talk to you in Boston at the AGFA kickoff for DRUPA 2000.Cheers,Henrik