Linux.com

They call themselves "The OpenDocument Foundation", but they're still just 3 people. Were they really worth writing an article about?

#

If it's three very VOCAL people, who a lot of people were listening to before, then yes, you need to do something to counter their arguments. If it was just me posting on my little bolg that no one other than my family reads anyway, then there wouldn't be any reason to even notice. However, it's clear that a lot of people (especially people with an agenda to spread FUD anyway) are taking notice, and suddenly it's a whole lot more than three people talking.

#

The Foundation wanted to sell a plugin which converted Microsoft files "flawlessly". In order to do this, they extended ODF with various attributes to stuff with bits of RTF - at the time they called this the "dark matter".

The problem with such an extension is that no other ODF app (e.g., OpenOffice.org) will recognise it, and such extra data gets jettisoned if you open it in such an app. So, they tried to persuade the OASIS TC to make it mandatory that ODF compliant apps treat non-ODF extensions with kid gloves: to not change it, to re-save it out, and to somehow perform magic when the document is modified. Of course, that was unreasonable.

The OpenDocument Foundation was all about this RTF trick to make ODF documents save as much proprietary Office info as possible, and they readily admitted that no ODF app like OOo would be able to open such ODF documents and achieve the same formatting as in Word (which is obvious, really - all the real data was in the dark matter). So what we're hearing now is the clip-clop sound of this one-trick interop pony trotting down to the knacker's yard.

For all their talk of grand plans, all they ever produced was a Word plugin which essentially serialized RTF into XML, and this was supposed to be impressive. Serializing and storing Word data isn't hard, stuffing it into ODF documents is only moderately more complex. I rather think people will wait to see something a bit more interesting before they listen to any more hype and hot air.

#

Take out the "English" on this and it's not a bad synopsis.

With its Plug-in, the Foundation solved a problem everyone said was unsolvable. Preserving metadata, binary information and other "dark" or foreign matter is necessary for enterprises to cope with the installed-base of MS documents. It's that simple.

Without it, no OpenOffice.org adoption, which means no ODF adoption. Massachusetts established this requirement. No ticky, no shirty.

-Sam Hiser

#

The Foundation didn't solve the problem; it ignored the problem. Preserving the data from Office is easy, and sticking RTF-as-XML as foreign attributes in ODF is easy. What is hard, and what the Foundation didn't solve, is translating that stuff into genuine ODF tags as defined in the ODF standard. And the Foundation cannot solve that because they can't decode the "dark matter" any more than Sun or anyone else can without MS docs.

Stuffing Office proprietary info into an ODF file doesn't make it ODF. It makes it ODF + proprietary info. Fantastic if you're an MS Office user, but it doesn't get you anywhere. You can't use those documents in other apps, like OpenOffice.org, without loss of formatting, with or without the snake oil "interop eXtensions". That data is *still* trapped in MS binary encoding, and that's what you just don't get.

#

And you want me to believe in these open source lunatics .... LOL

#

The article itself is very worthwhile as this is a real imbroglio.

I have already concluded about tech people not knowing jack about real world markets and the struggle to put M$ in its due place... CDF might even be the best format in the future (who knows? I don't), but clearly the hot stuff now is ODF.

Let's hope they have better luck than MIguel, who also has shown some jawdropping POVs ("Unix sucks")...

#

<a href="http://www.robweir.com/blog/2007/10/cracks-in-foundation.html">http://www.robweir.com/blog/2007/10/cracks-in-foundation.html</a>

#

...Nothing More

#

The argument that OpenSource is too big a risk just got a whole lot stronger.
Thanks Guys.

#

The argument that OpenSource is too big a risk just got a whole lot stronger. Thanks Guys.

Thank you too, astroturfer!

#

I suppose that when something bad or controversial happens in the open source or the free software communities, a choice has to be made. We can choose to remain transparent, honest, and aboveboard, or we can sink into the quagmire of lies, distortions, omissions, disinformation, and disingenuity for which the non-free Windows ecosystem and trade press is rightfully notorious.

IMO you can't have it both ways. With freedom comes some degree of responsibility, and it is an unfortunate fact of life that not everyone is equipped to deal with it, opting instead to remain in chains, and choosing to be spoonfed the propagandized pablum so carefully prepared and sterilized by their corporate masters and their shills, rather than weighing the facts and making their own decisions.

#

Of all the "journalists" on this site (or anywhere else, really), you
are the most biased, tinhat wearing, FUDspreading, whining, sniveling
author around. You present misleading and slanted information on a
regular basis so who the hell are YOU to use words like "distortion,
omissions, and disinformation"? With journalism comes a degree of
responsibility as well, and there are many true journalists who you
could learn from.

It's bad enough that you write crap like this, but at least have the
nads to take criticism when it's due. You presented half a story (as
per usual on this site lately), and got busted for it. Your fanboyism
is annoying at best and a little scary at worst but, over all people
like you and your hysterical zealous rants are part of what keep open
source from being taken seriously.

Keep your petty blog-worthy rants off this site and maybe linux.com
would get taken seriously as a real place to go for news instead of a
bunch of fanboys sitting around patting each other on the back. This
site used to be useful and full of good information. Now it's nothing
but a pit of negative, whining, crap studded with the occasional
informative or helpful article. It's been harder and harder to find a
reason to come back here when there's so much better, and less
wheedling, information to be had elsewhere.

I can't stomach this crap anymore, it's not worth sifting through shit
like this to get meaningful information or interact with other FOSS
users. If I want forum-worthy fodder, I'll hang out on Slashdot. It's
not about disagreeing. Friendly disagreement among enthusiasts is
common and even useful. At the point where a sermonizing "commentator"
browbeats its readers for DARING to have a different opinion on a
clearly biased story (again, as so many linux.com stories are these
days), I know it's time to leave. In an effort to keep people new to
the community from thinking everyone is like you and some of the other
authors here, I'll be sure to share my opinion of linux.com with
anyone who will listen, and actively steer people away from here. I
want Linux to survive and thrive. I can't say I want the same thing
for Linux.com in it's current state.

That's "what's wrong with Linux.com", since you asked.

#

Your rant defeats the very point you were attempting to make. I'm actually glad to see Joe call the OpenDocument Foundation's bluff. They are deceivers, constantly getting press that they do not deserve. They have often been quoted as an authority by the computer pubs, who have been snookered by their official-sounding name. They have no official relationship with the ODF bodies, and have not contributed to the ODF format in any tangible way. They advocated the format for personal gain, and when they failed to achieve that gain, they turned traitor. The only reason they get press is because of their name. They thought they could use their vaunted name to unseat the ODF with a vaporware standard. It turns out that their power and influence is itself just vapor.

#

nm

#

That was "darkFormat" -- my science-fiction twin.
LOL! Made my day ;-)

#

"Of all the "journalists" on this site (or anywhere else, really), you are the most biased, tinhat wearing, FUDspreading, whining, sniveling author around."



Really? He is? So prove it. Provide a quote, a reference to an article, anything. You offer absolutely zero evidence to support this claim.



"With journalism comes a degree of responsibility as well, and there are many true journalists who you could learn from."



Like who? Are you so uninformed of the subject you're ranting about you can't provide a single example?



"You presented half a story (as per usual on this site lately), and got busted for it."



He did? Where? When? How? By whom? You offer NO information to support yet another baseless claim.



"It's been harder and harder to find a reason to come back here when there's so much better, and less wheedling, information to be had elsewhere."



Don't let the door hit your ass on the way out.



Oh, and learn to format your posts into paragraphs. And don't whine about how they need to use nl2br. Everyone here should be intelligent enough to know how to insert <br> tags into their posts.



-Jeremy

#

Thanks for your feedback :)

#

Hi Joe-

I've seen better from you.

If one substituted 'CDF' for 'ODF' in what I have said in the past, my statements would be perfectly consistent. ODF is better and on some important ways still more open than the Kafka-esque OOXML. Also, some of my statements about ODF as a standard still hold; mainly now we are talking about its implementation, which is quite different & nuanced thing.

Potts will wish he'd held comment on CDF, where he's out-of-depth.

See you 'round & best wishes,
-Sam Hiser

#

I read somewhere that ODF documents created in KOffice can be automatically altered when imported into OpenOffice in ways that trash the formatting. That's a real issue for me. I'd like to go to all open source...but OpenOffice performs too slowly for me. It's gotten better over the years but Its too still too slow for me to commit to for now. I'd like know that whatever ODF program I use today will create documents that won't get trashed if I want to switch to another ODF compliant program in the future.

From that standpoint what Sam Hiser has been blogging about seems relevant.

#

One of our issues with ODF -- a show-stopper, in fact -- is that there's no compliance testing suite. What's with that? How can you be about interoperability if it is not seamless | brainless | frictionless to implement, re-implement and implement all over again the format in any possible application? What does that tell you about the objectives of Sun & IBM? I'll answer that: they either want to own the MS-alternative office application space or they do not believe that office productivity apps are being commoditized or commoditizable (by the Office 2.0 gang) ... or both. Our position is driven by enterprise CIOs, who reject both propostions vehemently.

W3C has a rigorous testing regime for CDF -- the CDR.

Got Compliance?

To answer your question: CDF will be the Universal Document Format and every word-processor or office productivity suite module will be an equal-opportunity-interface. MS Office, OpenOffice.org, Zoho, Buzzword, Gdocs, Abiword, KOffice, and some we've never heard of -- will all participate. If they elect not to, then they will possibly experience user-erosion...I don't really care what happens to them because I don't see any of them NOT participating.

How do we get there? I wish we were there 12 months ago. But we are thinking hard about how to do this.

#

First, CDF isn't a format. You know this full well. CDF is a way of combining multiple formats, it's a container. So, unless you're making up a completely new proprietary language, you're saying that you think XHTML is enough to store office documents in.

Second, the CDR isn't a testing regime - where on earth did you get that from? The CDR is a way of referencing other documents and doing stuff like propagating events. It says _nothing_ about conformance to document standards, go read it: http://www.w3.org/TR/CDR/




Wake us up when you've actually got some CDF files to show us. Assuming it's not more RTF serialized as XML, which no-one except MS Office has a hope in hell of understanding.

#

You said, referring to ODF, "They are all about interoperability." In fact, the very point we have been making is that ODF is a non-interoperable set of formats. But don't accept my word. How about the word of Thomas Zander, lead developer of KDE KOffice's word processor, KWord:

"One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that's useful to me and then save it and continue in KOffice without loosing lots of data. Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal." http://www.oasis-open.org/archives/odf-adoption/200709/msg00032.html

How can such a situation exist? It is because ODF does not comply with ISO/IEC JTC 1 Directives as to interoperability: "Standards designed to facilitate interoperability need to specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." http://www.jtc1sc34.org/repository/0856rev.pdf (pg. 145). But don't take my word for that either. Ask someone who is telling you ODF is an interoperable set of formats to point you to where the interop conformance requirements are in the ODF specification. Good luck, because they don't exist.

The interop warts in ODF are not limited to interop with Microsoft Office. They are severe. And in fact, interoperability is not even a requirement in the ODF TC's charter. http://www.oasis-open.org/committees/odf-adoption/charter.php (.) If you check this post by the newly-elected ODF TC co-chair, Rob Weir of IBM, you will learn that the plan is not to clean up the interoperability mess before several iterations of the specification. "I'm more inclined to take a conventional approach to interoperability, meaning ***iterating*** on the text of the standard to eliminate ambiguities, work on test suites and compliance tests and eventually logo certification. "
http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2007-November/002942.html

I have read your articles for years and believe that you have earned your readers' trust. But you are attacking the only people who were willing to stand up to Sun and IBM's abuse of the ODF Technical Committee to limit interoperability not only with MS Office but also among ODF implementations. There is far more to this story than you recognize. See e.g., our article here, which is thoroughly referenced. http://www.linuxworld.com/news/2007/072307-opendocuments-grounded.html (.)

I believe you owe it to yourself and your readers to dig a bit more deeply into the situation. And I will happily provide thorough documentation. Digging on this situation is a continuation of my original research and writing that turned the file format wars into a public issue worldwide. http://www.groklaw.net/article.php?story=20050330133833843 (.)

There is no shortage of proof.

I will also correct a misstatement by my colleague Sam Hiser. The OpenDocument Foundation has one remaining project relating to ODF before dissolving the corporation, a detailed proposal for the ODF TC to repair the interoperability barriers presently in the standard. I am the Foundation's remaining member of the ODF TC and am in charge of that project. But I suspect it will be met by the same cries of outrage we experienced when we previously filed bug reports against the specification.

Some people with a commercial dog in the fight wish to perpetuate the myth that "open" can properly be conflated with "interoperable." They are not synonyms. Interoperability also entails conformance requirements, as required by ISO, such as a prohibition against destroying markup created by other conformant applications. Today, ODF includes no such requirements and Sun Microsystems has taken full advantage of that fact to ensure that no other featureful ODF app can round-trip documents with StarOffice/OOo without lossiness.

If you care about the quality of standards FOSS developers support, I urge you to get the facts right in this situation. The real story is an old one, big vendor abuse of standards for competitive advantage.

If you wish to understand what is really going down, please feel free to contact me via my email address on the Foundation's contact page.

--Marbux

Director of legal affairs

OpenDocument Foundation

#

What is it with you guys? The more words you spew, the more you sound like you have no idea what you're talking about. You want to embed closed, proprietary crud in an open document format. It's not open anymore when you do that, and it avoids the core problem, which is microsoft's resistance to a truly open, interoperable document format. You're not fixing that by caving in to them. Only Microsoft has the ability to make MS Office fully support ODF. They just don't want to. That's their problem, not everyone else's.

You might try presenting facts and understandable arguments, rather than attacking the people who disagree with you. But it appears you don't have those.

#

I keep seeing posts about CDF trying to fix the MS document and ODF document interoperability problem. That may or may not have technical issues. Frankly I'm not technical enough to know, and I don't realy care about that either.

But I do care about ODF applications working seemlessly. If I am collaborating with a team on Google docs (and I do) and I want to pull it into OpenOffice.org to work on it offline I don't want the document to be all screwed up. If they are both natively ODF I expect that there will be no problems on the round trip. From what I read it appears that there's guarantee that will work for now. And, if that's the case, it should be addressed.

#

Well, lets put some logic behind this:



If I open a document in KOffice, save it, open it in OpenOffice, and save it, and the document loses data from KOffice, then -someone- isn't following the ODF standard. IE: Someone is saving data that is not supposed to be there.



Switching to CDF is not the answer. The answer is to force applications to comply with the ODF standard. If there's some feature missing from ODF that many different applications need, then add that feature to ODF. But don't add it by forcing applications to treat unknown data like it's supposed to be there. All that does is encourage developers/vendors to embed proprietary bits into an otherwise open format. If you want to add a feature to the format, add the feature to the format. Don't just go, "Ok, here's the features of the format, and oh yeah, if you see extra stuff that's not supposed to be there, treat it like it should stay there." That's stupid.



Duh!



-Jeremy

#

Hi Paul,

Thanks for quoting me.

Paul(aka Marbux) wrote:
How can such a situation exist? It is because ODF does not comply with ISO/IEC JTC 1 Directives as to interoperability

Nah, that's not the reason. The real reason is that ODF has not been around for that long and it takes time for applications to fix their interoperability bugs. Consider that for a moment. You have an application saving and loading a feature just fine, but there was no other application capable of loading that feature yet. How do you know you implemented the ODF feature correctly? That is hard, and takes time to flush out.

The cool thing is that you linked to a mail in a thread that is exactly meant to tackle this issue. There has been a meeting of all the implementers of the various ODF implementations and they created real-life documents in one app and tried to open it in another. All the problems got jotted down and are planned for fixing.

The idea is to have such a metting at least once a year and thus strive for the interoperability that people want.

We are not there yet, ODF documents are not interchangeable enough in some ODF-implementations. But we are getting there.

Also, one thing has to be made really clear here; ODF-compliance is a feature that the market requires (as you can see from this thread alone) so if one odf-implementation doesn't fix their issues, people will stop using that implementation and switch to another.

That's the beauty of an open market and the direct result of the open standard we created here.

Thomas Zander

ODF-technical committee member and KWord core developer.
[Modified by: Thomas Zander on November 10, 2007 01:03 PM]

#

So.... has anyone else come up with a reasonable technical analysis of CDF? It's supposed to be a standard already. I agree that the current argument seems to be a tempest in a teapot, and I don't think any of the REAL players are thinking about dropping ODF, but are there any advantages to CDF, other than the claim that it can more "faithfully" reproduce MS formats? Has anyone out there actually created an application that will read/write/render/edit the format? Is it nothing more than a way to say, "Put proprietary formatting information in these binary tags here...", and call it "XML"?

#

The more you rant, the less credible you look.

#

I'm happy to address questions or criticism to anyone who logs in.

#

Greetings, I'd like to ask you a few questions then...

1) Are you really going to wind down the "Foundation"?
2) How are you going to address the fact that Microsoft's Office products produce proprietary formats? What about the "BIFF" format which will still be embedded in OOXML?... How is anything you do with CDF going to cope with the still-proprietary format there, and how will anything you do with CDF be able to produce a truly Open format which any program will be able to open and display the document precisely in the manner in which it was presented in another product?
3) Do YOU think Microsoft really /wants/ any other product to be able to read, display, and save data in a manner which allows the other products to seamlessly interoperate with Microsoft's products, OR vice versa?
4) In my article on my web site, I criticised the /foundation/ for diluting the "ODF" acronym, and for also allowing mainstream media to create FUD-laden articles about the Open Document Format - do you agree with my analysis, and if not, why not?

Regards,

Kevin Cave.
http://hackfud.net

#

Kevin, Thanks for your questions. I'll try my best:

1) yes, its original purpose was to help develop ODF and we are directing our atttentions to CDF and other areas in part because ODF development is moving into better governance and into smarter hands (IBM);

2) we have a da Vinci plug-in which has demonstrated our capability of accessing MS documents in high-fidelity form (find it here: <a hre="http://opendocument.foundation.googlepages.com/home">ACME 376</a>); this uses Microsoft's own plug-in architecture INSIDE the respective MS Office application to capture the document content and layout information in its in-memory representation in its "secret RTF" form; sometimes there is binary, OLE, VBL information which can't be accessed and that is maintained in metadata so that it can be used if the document should ever return to its native application. It's not perfect but the da Vinci fidelity is close to Microsoft fidelity; Sun plug-in is free of charge but not Free and is about 85% fidelity or similar fidelity as the OpenOffice.org application; Microsoft's plug-in fidelity we have experienced below 65% fidelity performance.

3) I am certain they do not.

4) We are creating software which will eventually be judged on its merits. I try to keep FUD or other non-essential discussion -- particularly uninformed speculation (by anyone) -- off my screen so we can focus on the success of our enterprise.

#

CDF is a standard framework for combining different kinds of document standards. That's correct.

#

So, inside the CDF files you want to produce, the document standard in use will be what, precisely?

#

XHTML + CSS is the base. Add XForms, SVG and SMiL where needed. Study the work being done on microformats. Like most modern portable XML file formats, the basic packages are those of content and presentation. In CDF speak, this is XHTML content and CSS as the portable presentation package. ODF and MS-OOXML both struggle with the legacy tradition of the presentation package being application specific. Meaning, the portability is limited to other applications that are either of the same version, or, share the same layout and rendering model so that the exchange of the presentation package is lossless.

Document processing experts like a clean separation of content and presentation because they expect each application to preserve content but replace presentation. Think of sending desktop office suite documents to an enterprise publication, content and archive management system. In most cases a pre written template must be used at the desktop level to facilitate the exchange. In a document processing experts ideal world, they would prefer to skip the application specific template management, focus on the end user expertise with content (not presentation), and simply re purpose that content at the enterprise level.

End users on the other hand are always chomping on the controls, wanting to have more say in the larger document exchange process. They expect preservation of both content and presentation, across many application exchanges, with presentation approaching PDF like qualiity. And so it goes.

As a backdrop to these discussions, there is the movement of everything to the web platform. Instead of the traditional application to application problem, we now have to consider the desktop-device-web application to web platform issue. This is where CDF shines.

Imagine the question being framed in terms of converting desktop office suite ODF to CDF versus converting MSOffice MS-OOXML to CDF. Meaning, which one is web platform ready?

IBM, the W3C, and the OASIS Lawyer now argue that CDF was never designed for this role. That it is impossible to do. They are the experts. They must be right.

Microsoft on the other hand has no intention whatsoever of implementing a web platform solution based on W3C technologies. MS-OOXML was designed exactly to work across the desktop, server, device and web platforms. The MS Stack of applications includes MSOffice at the desktop, the Exchange/SharePoint Hub, the IE browser, with MS Dynamics, MS Live, MS Office Communication Server, MS SQL Server, Silverlight, etc. In fact, the MS Stack flows wherever .NET Foundations Libraries are used.

MS-OOXML is a MS Stack solution negating the need to ever consider a W3C technology such as CDF, HTML, XHTML, XForms, SVG, RDF, etc. Nor do they need PDF. The swarm of MS-OOXML - Smart Tags - XPS -XAML combinations is fundamental to those .NET Foundation Libraries. Meaning, there is no need for W3C technologies.

Given the recent statements by IBM, the W3C and the OASIS lawyer, even if Microsoft was pressured to use CDF as a container of compliant W3C technologies, they can now argue that this file format framework was not designed to meet the needs of desktop office suite conversions.

This brings us to an interesting dilemma. On the one hand we have ODF leader Sun claiming that we need multiple file formats, and ISO should approve MS-OOXML because ODF was not designed to be compatible with MSOffice documents, applications and processes. And on the other hand we now have IBM, the W3C and the OASIS lawyer claiming that you can't use CDF for the resonant reasons that CDF was not designed to meet the conversion needs of desktop office suites. Hummmm.

That leaves 550 million MSOffice desktops wanting to migrate to XML, and fully embrace the collaborative web platform of the future with what? MS-OOXML! And MS-OOXML leads to one thing and one thing only. A web platform dominated by the proprietary MS Stack of MSOffice to MS-OOXML to Exchange/SharePoint and beyond.

One of the reasons i think the world struggles to understand the problems of coming up with an alternative to MS-OOXML and the emerging MS Stack, is that the file format issue is cover for the real problem. It's the perfect camouflage. If the only problem was that of having your information locked into a proprietary file format, the world would have gracefully moved to ODF years ago. The OpenOffice conversion process is more than good enough for that task. But that's not the core problem. The real barrier is that of MSOffice bound business processes. The binary file format is only one aspect of business process lock-in. The other challenge is that of a MSOffice developer platform binding created through years of line of business, VBa scritping and add-on development. How do you crack that?

One way to deal with this MSOffice bound workgroup-workflow business process challenge is seize upon the rare opportunity that came about as Microsoft started to migrate these MSOffice bound business processes to the Exchange/SharePoint developers hub. The transition of existing MSOffice documents, applications and processes to MS-OOXML has a purpose; to use the web platform as an end game strategy effectively extending the monopolist desktop marketshare to servers, devices and the web. The first stage of this leveraging is the transfer of MSOffice business processes to the Exchange/SharePoint Hub, where newly designed collaborative processes quickly replace the comparatively limited, inefficient and brittle desktop generations. The productivity rewards alone make this transition beyond valuable to end users.

Is it possible to intercept this transition of business processes, and re direct them to open source Exchange/SharePoint alternatives? I think so. But to pull this off one has to either neutralize and re purpose MSOffice with an in process conversion facility (an ODF or CDF plug-in clone of the MS-OOXML Compatibility Pack would be one approach, but only if these file formats could be specifically tailored and adapted for that purpose). Or, one could go the disruptive and costly rip out and replace of MSOffice route. A choice Munich has made that is now costing them over $3500 per desktop. Liberating but kind of costly.

Imagine though if you were able to intercept MSOffice business processes at the head point, and push them to open source Exchange/SharePoint alternatives where they could be re written with explosive collaborative value? The key here would be to neutralize the extreme advantage Exchange/SharePoint has over competitors - the advantage of document level integration into existing MSOffice bound business processes. Microsoft perfects this integration through the MS-OOXML Compatibility Pack plug-in. Using this, they control the migration of existing business processes by limiting the server side - collaborative computing choices end users have. It's not that there aren't open source alternatives to the Exchange/SharePoint hub. There are great alternatives out there. What they lack is interop with MSOffice at the business process level. And Microsoft is not about to make it easy by offering up that interop. Least ways not until the migration is complete, and new lock-in established. One that will last for years to come, stretching across a new monopolist empire of desktops,servers, devices and the web.

In the end, users will select the most pragmatic solution available. The real challenge is providing them with alternatives to the MS-OOXML Compatibility Pack plug-in and the certain migration of business processes to Exchange/SharePoint Hub and the MS Stack that goes with it.

#

Exactly, so CDF isn't a markup format at all, it's a container for other markup formats. Which begs the question, what formats are we going to shove into CDF to actually create a working document?

#

XHTML, CSS, SVG, XML, ODF... many others. Since OOXML and the legacy MS documents contain non-standard elements, we will use the Microsoft plug-in architecture to "pipe" a high fidelity stream of content and layout into XHTML within the CDF container. We have achieved Microsoft-quality performance fidelity to original MS documents. We will use tools on the desktop to "retrieve" or "go and get" legacy formats; however, what I call the Universal Document will exist at the server "hub".

CDF in our vision is principally a server-side Universal Document Format (i.e., containter). It is largely consistent and complementary to ODF as a strong & widespread format on the desktop.

Yes. Our software is a direct attack on MS Sharepoint.

#

None of which explains why your original announcement expressly claimed that ODF is going the wrong direction, and that CDF will replace it. And why is this necessary? For only one reason. Your "compatibility" plugin didn't work well with ODF. And why is that? Because your "compatibility" plugin was nothing of the sort.

Tsk, tsk. The thing about the web, Sam, is that you can't re-write history without somebody noticing.

Anyway, moot point now. I can't link to your original announcement, because it seems you boys have thrown in the towel. I guess that is what happens when an organization loses all credibility.

#

"we will use the Microsoft plug-in architecture to "pipe" a high fidelity stream of content and layout into XHTML"...



ROFL



You expect anyone to believe that load of crap? You sound like a salesman trying to inflate his product to make it sound better, throwing out buzzwords like XHTML and XML that people are familiar with but don't really understand. Basically you just "act" like you know what you're talking about so people who don't know better just believe it. Anyone who is at least halfway almost technical would look at that statement and go "WTF is that guy talking about?" The problem with doing that here, is people see right through it, so if you want to get people on your side I'd suggest stopping the sales act and start talking about specifically how you intend to use CDF in place of ODF, especially since the W3C folks who are behind the CDF design have no idea why you'd try to use CDF for this purpose.



-Jeremy

#