You hand out this ribbon far too easily. Parallel offerings[1] are pretty much guaranteed not to be parallel (or resemble it even enough to fool those who want to be fooled).
1. Separate-but-equal, or whatever you want to call it
That said, the point of parallel offerings is not to provide identical representations of a given resource. Even XML+XSLT versus XHTML might have different semantical implications, so the best assumption is that no two ways of representing a given content can ever be identical.
Well, that's a Good Thing. If I'm requesting a given resource and I signal preference for a PDF-encoded response, that implies on some level that I want a print-formatted, print media version of that resource, whereas its HTML counterpart can be hypertext and multimedia.
What you as a server are committing to is that both servings are representations of the same given resource, but without prejudice of putting each format to its best use.
This is also beautiful in that if the HTML stack proves to be a bad idea in the long run, rather than being deprecated, it can fall into disuse slowly alongside the slow rise of its successor(s). In fact, there's absolutely zilch stopping us from having more than one canonical format — any server-side MVC (or MVCish) architecture can probably handle that off the box!
EDIT: to be sure, the question of how expensive it is to develop for two different representation formats is a whole other story.
If it helps, it doesn't look like you did. :)
> without prejudice of putting each format to its best use
Doing what you can to the extent of what's possible with multiple mediums (yeah, mediums, I said it) is real pie-in-the-sky, false promise kind of stuff.
People can't manage today to put the web to anything you could mistake for its best use. Why should it inspire confidence when anyone says it's going to happen when their resources are halved?