Comment on Microsoft, ECMA, and XPS

In the last couple of weeks I’ve run a two entries (here and here) regarding Microsoft‘s submission of its XPS specification to ECMA. I raised some questions along the line that this was the OOXML situation all over again, namely forcing a proprietary product spec through a vendor organization and then possibly to international standards status.

A few of the comments to those entries said that I had it all wrong and that this was really a group industry effort (see those by nemo, for example). Today I got a note from Kevin Andresen, Director of Product Marketing, Print Language and Driver Software, for Zoran in Woburn, Massachusetts. He too felt I got it wrong — I sense a pattern (grin) — and said Zoran’s

implementation and several others — by printer manufacturers, application developers, and third-party technology providers — were indeed a) developed independently from Microsoft, and b) run on several operating system platforms other than Windows.

He also pointed out that Adobe did not submit PDF to ISO until after Microsoft announced that they would open up XPS.

The comments closed on the other entries, so I added this here so people could discuss the situation. Kevin assures me that he will take part.

The big picture here is that we want to move to truly open standards for software interoperability. It is not my intention to try to find fault for fault’s sake in what others do, but rather to be part of the movement in the right direction. I would be thrilled if XPS is not OOXML 2, the sequel.

This is our chance to discuss what got us to this point and to get some assurances that what we will see in the ECMA deliberations are truly open and transparent. Let’s flesh out all the details. I encourage the other ECMA TC46 members to take part in the discussion as well.


This entry was posted in Document Formats, Standards and tagged , , , , , , , . Bookmark the permalink.

8 Responses to Comment on Microsoft, ECMA, and XPS

  1. Chris Ward says:

    So what is it that XPS can do, but PDF can’t ?

    I’m willing to believe that PDF isn’t the perfect answer for getting images onto paper (and for previewing images that may never get to paper). But (as I commented before) I could probably design a more efficient auto engine if I could allow for half-a-dozen foot controls to adjust fuel-air ratio, compression ratio selection, and so on. Most people stick with gas and brake pedals, though, and the auto with the half-dozen pedals would likely not sell too well.

    So, is XPS ‘different for the sake of being different’, or ‘different and better’ ? Is there any reason why IBM might want to invest in implementing it for z/OS and mainframe printers ?

  2. Bob,

    To your attention:

    http://blogs.zdnet.com/Newton/?p=16

    They go to the UK now (not exactly news.

    Also see the following.

    http://news.zdnet.com/2100-3513_22-6173625.html

    I’m with the OSC, but the that’s not a case of bias. It’s true.

  3. Another one headsup: http://www.linuxworld.com.au/index.php?id=1180812442&rid=-50 ( TurboLinux to help translate Open XML for Asia )

    Insanity, eh? It could be worse. No IP FUD for a change.

  4. WuMing Shi says:

    My two cents:

    Do printer manufacturer, most non-office application and those who only consume (not create) XPS or any other document type really need “Open Standard” to operate?

    Me don’t think so. All they need is the full specification. Using the same principle, XPS or other document type generating application does not need open standard, but full and complete specs to operate.

    To qualify as Open Standard I will have to use Sutor’s principle that participants has the ability to influence the standard. With this I don’t mean requesting clarification here and there, asking the vendor to beef up information here and there. I mean influence it where it matters, i.e., BY MAJORITY VOTE, force the vendor to change part of the specification eventhough it doesn’t want to. In other words, the vendor who proposed the format should NOT have a veto.

    Otherwise, use another process, as it is not standardization. And don’t call it standardization. It’s not. One example where this process will go is Microsoft’s API development work with Hardware Vendor. Microsoft do listen, but they have the final veto. The process actually works very well. The process will never satisfy the “openness” criteria, but who cares?

  5. Kevin Andresen says:

    Chris,

    One of the greatest benefits of XPS (albeit Windows-only) is that it provides a Control-P print experience with a modern print language. Although PDF can achieve many of the graphical effects of XPS, it has been very difficult to date to send PDF files directly to a networked printer — even those that can print PDF files natively. XPS is used as the internal spool file format for Vista (and XP with .NET 3.0 installed.) There are a number of more subtle differences and improvements that don’t impact XPS’ utility as a standard.

    WuMing,

    It is true that most print languages today are de facto standards rather than Open Standards — however, the devil is in the details of how their owners implement the language vs. what the specification implies — it’s also the case that Adobe gets a head start each new version of PDF (or PostScript) and likewise HP for PCL. The ability to resolve ambiguities more formally and to participate in new versions as they are defined is an improvement over the status quo for independent technology vendors such as Zoran.

    A look at the members of the Ecma TC46 Technical Committee shows a large number of interested parties, many with XPS implementations of their own (both creators and consumers), and many of whom also gave input to Microsoft on the design of the language before its publication. We have no reason to doubt that the Technical Committee will have the power to influence the standard — whether the process will leave every participant satisfied (including Microsoft) remains to be seen, but such is the case for any industry-wide cooperative endeavor.

  6. WuMing Shi says:

    Kevin,

    Your reply to Chris’ where you use Control-P is a catch22 situation. MS could had chosen to implement a way that send PDF document flawlessly or come out with its own standard. As for improvement, MS could had chosen to improve on PDF. Perhaps it finds that its embrace->extends->extinguish policy just cannot work with PDF because of licensing constrain, it choose to define its own format. I am, for example, unclear why MS choose not to fight Adobe in Adobe’s EU complain about XPS and PDF but instead DROP XPS from Microsoft Office 2007 CD. It is a strong hint that MS find that the complain can be upheld.

    As for your reply to me about “Devil is in the detail”, machines only understand what the programmers tells it to do, as soon as you have multiple implementations,whether you choose the de facto standard or Open Standard route, you will have deviation from the standard. No standard can nail it so precisely that deviation will not occurs. Just look at ISO C and C++ standard, after 20+ years we still have intepretation problem. Some organizations practice the use of a “reference” implementation to reduce such problem. With PDF, PCL and XPS, we know who own the default implementation. PDF is more successful probably because Adobe is more forthcoming with its implementation detail than PCL. I hope XPS is more clear in its implementation detail than Adobe

    Satisfying every participant is too high an order. I will say a standard is successful if (1)there is no major serious problem that are very obvious, e.g., the date problem with OOXML and (2)the majority of the participants feels that it was worthwhile. As for the specific case of Microsoft, I cannot see it being in the minority of dissatisfied party… all it has to do is to pull its contribution from ECMA if it is unhappy.

    One point pointed out by Rob Weir, which you see MS and (lately) British Library’s Mr Farquhar (TC45) tries to dispel, is that ECMA is not as open as OASIS. We see only snapshots of information from ECMA, and it is highly filtered information and thus insufficient for me as a non participant to figure out whether is it a nodding party for Microsoft or not. That is part of the problem: Even if MS is truely open, we cannot see it! With Steve Ballmer’s big mouth, it is one step forward then two steps backward.

  7. John Scholes says:

    Can anyone give me a concise history of the Adobe/MS row over XPS? Did Adobe ever submit a complaint to the EU, or did it merely threaten? Is the ability to save as .pdf in the current Office 2007 or not? I am afraid I have not been paying close enough attention :(

  8. Kevin Andresen says:

    WuMing,

    I suspect that if Microsoft chose PDF for Vista but then modified it to do what XPS can do, we would hear even greater cries of “embrace and extend” (though note that Apple has done essentially that with the version of PDF used internally by Mac OS X.)

    There is no true “reference” implementation for XPS *printing*, and many aspects of the language cannot be accurately rendered on the Windows display by Microsoft’s implementation. It seems a Good Thing if multiple vendors, each with their own interepretation of ambiguities and their own deviations, are part of the committee to clarify and improve the spec.

    John,

    The short version is that Microsoft claimed that Adobe complained to the EU about “Save as XPS” and “Save as PDF” being bundled in Office 2007. Microsoft removed the functionality from the retail product and made it available as downloadable plug-ins:

    http://www.microsoft.com/downloads/details.aspx?FamilyId=4D951911-3E7E-4AE6-B059-A2E79ED87041&displaylang=en

    Here’s a contemporaneous account from the Microsoft TPM for XPS:

    http://blogs.msdn.com/andy_simonds/archive/2006/06/02/XPSAdobe.aspx

    Disclaimer: Zoran has no dog in this fight — we have interpreters and customers for both PDF and XPS.

Comments are closed.