Home
Gary Edwards's Library tagged → View Popular
ODF infighting could help Microsoft's OOXML - zdnet Mary Jo
-
As a result of the latest infighting, is Microsoft now all-but-guaranteed that OOXML will sail through the ISO standardization vote in Feburary 2008 because ODF — and its backers — will be in disarray? This has nothing to do with the outcome of the Ballot Resolution Meeting.
-
But we also oppose adoption of ODF 1.2 as an ISO standard in the form we expect it to emerge from OASIS.
- 1 more annotations...
GROKLAW - W3C's Chris Lilley: CDF Not Suitable for Use as an Office Format & Can't Replace ODF
I (IBM operative PJ)put the link to Andy Updegrove's article in News Picks earlier, but this is too important not to inform you about here as well. As you know the so-called OpenDocument Foundation has been telling the world that CDF is a better approach than ODF. Updegrove met with W3C's Chris Lilley, the "go-to guy guy at W3C to learn what W3C's CDF standard is all about." Lilley says CDF can't replace ODF. It's not suitable for use as an office format, and he's mystified by the pronouncements of the Foundation.
-
This is priceless! The ODF Community is now attacking the W3C and CDF. Watch what happens next inside IBM and Sun who are the primary supporters of CDF. You see, the thing about a mob is that there comes a point when you can no longer control them. We've reached 451 Fahrenheit. somebody is goign regret ever having lit that match.
- garyedwards on 2007-11-10
-
As you know the so-called OpenDocument Foundation has been telling the world that CDF is a better approach than ODF. Updegrove met with W3C's Chris Lilley, the "go-to guy guy at W3C to learn what W3C's CDF standard is all about." Lilley says CDF can't replace ODF. It's not suitable for use as an office format, and he's mystified by the pronouncements of the Foundation.
Here's what Updegrove reports:
To find out the facts, I interviewed Chris Lilley, the W3C lead for the CDF
project, and his answer couldn't have been more clear: "The one thing I'd
really want your readers to know is that CDF was not created to be, and
isn't suitable for use as, an office format." In fact, it isn't even an
format at all - although it has been matched for export purposes with
another W3C specification, called WICD - but WICD is a non-editable format
intended for viewing only. Moreover, no one from the Foundation has joined
W3C, nor explained to W3C what the Foundation's founders have in mind.
It is highly unfortunate that the founders of a tax exempt organization
that solicited donations, "To support the community of volunteers in
promoting, improving and providing user assistance for ODF and software
designed to operate on data in this format," should publicly announce that
it believes that ODF will fail. By endorsing a standard that has no
rational relationship to office formats at all, they can only serve to
confuse the marketplace and undermine the efforts of the global community
they claimed to serve.So, there you have it, straight from the horse's mouth. CDF can't replace ODF, according to Lilley. It wasn't designed to be used as an office format. It's good for other things.
So, was all this media push really about ODF? Or about damaging it with FUD and giving support to Microsoft's assertion that the world craves more than one office format standard so we can all struggle with interoperability complexity for the rest of our born days? And is it a coincidence it all happened on the eve of the next vote in February on Microsoft's competing MSOOXML? Was Microsoft behind this? Or did they just get lucky? Microsoft representatives, like Jason Matusow, certainly gave support to what the 3-man crew was saying, so much so that ZDNet's Mary Jo Foley wrote that, "the ODF camp might unravel before Microsoft’s rival Office Open XML (OOXML) comes up for final international standardization vote early next year." Dream on. ODF is doing fine. It's the OpenDocument Foundation that is shutting down.But here's my question: did the Microsoft reps not understand the tech, that CDF can't replace ODF? How trust-inspiring do you find that? Or did they think that *we'd* never figure it out? Whatever the story might be, unfortunately for Microsoft, people aren't as dumb as Microsoft needs them to be. FUD has a very limited shelf life in the Internet age. There is always somebody who knows better. And they'll tell the world.
Play the tape!!! The W3C eMails to the Foundation tell a different story | OpenDocument Format community steadfast despite theatrics of now impotent 'Foundation' | TalkBack on ZDNet - Flock
-
The W3C's Doug Schepers joins the discussion claiming that the Foundation misunderstood his eMail messages. We say otherwise!
There is of course one way to settle this: PLAY THE TAPE!
So here it is.
~ge~
- garyedwards on 2007-12-03
-
- An honest misunderstanding? Hardly! Play the tape!
Instead of arguing about who said what when, let's just go to the record and see exactly what the W3C's Doug Schepers said to us in an eMail introducing himself. Keep in mind that we did not contact the W3C or Mr. Schepers. The following eMail was most welcome, but entirely unsolicited.
Flow Document Overview
-
Uh OH! Look what Microsoft has put into the new .NET 3.0 SDK! Flow Documents is a Microsoft specific version of HTML that is part of the Windows Presentation Foundation Browser Developers Framework. XAML - XPS-XABL.
It also looks as though Microsoft has reserved MS-OOXML MSOffice level integration for themselves.
Another thought is that MSOffice is being positioned as a developers framework for Web 2.0 development. This docuemnt is goign to take some serious study. Bad news for IBM and Adobe for sure. PDF, Flash and AJAX are all going to be in the fight of their lives.
The conversion tools are going to become of critical importance. Some initial thoughts are that we could convert MSOffice documents to CDF+; convert OpenOffice documents to CDF+; and convert Flow Documents to CDF+, using the same XHTML 2.0 - CSS desktop profile (WICD Full). Converting MS-OOXML to Flow Documents however appears to be next to impossible by design. The easy approach would be to let the da Vinci plug-in perfect an internal conversion to either CDF+ or Flow.
It will be interesting to see if Microsoft provides a Flow plug-in for MSOffice. I doubt it, but perhaps there will be a demand from Flow developers. da Vinci could of course be configured to produce Flow Documents. At first glance, my assumption would be that the ability to convert native MSOffice documents and allication genrated Flow Documents to CDF+ would be the most important course to take. We''ll see. This is no doubt explosive stuff. Microsoft is truly challenging the W3C for the Web.
- garyedwards on 2007-12-17
The Future is CDF | Metaphorical Web - Kurt Cagle
-
As editing increasingly moves onto the web, its safe to say that the document of choice will be neither ODF nor OOXML, both of which gain their power on the basis of supporting legacy word processing systems. Instead, what seems to be emerging from the W3C is something that is not an office suite because it didn’t evolve from one, but that nonetheless is capable of most if not all of the same functions that office suite documents pose.
Debate Simmers on Why ODF Shuttered its Doors - Peter Galli eWEEK
-
Did the OpenDocument Foundation recently shutter its doors for good because it was unable to convince Oasis to support its converter, known as Da Vinci? Or was it because OpenDocument Format was simply not designed for the conversion of Microsoft Office documents, applications, and processes?
OpenDocument Foundation abandons ODF - PC Advisor Elizabeth Montalbano
-
However, a recent blog posting by Sam Hiser, vice president and director of business affairs at the OpenDocument Foundation, outlines why the W3C's (World Wide Web Consortium's) CDF (Compound Document Format) is a more viable universal format than ODF.
Former OpenDocument advocates bolt for W3C standard | Martin Lamonica
-
Great comments!
- garyedwards on 2007-10-29
-
Adding a twist to a high-stakes conflict over document formats, some advocates for OpenDocument, or ODF, are abandoning the standard in favor of the World Wide Web Consortium's Compound Document Formats standard.
The reason? Technical limitations in sharing ODF files with Microsoft Office applications.
But can they implement ODF? South African Government Adopts ODF (and not OOXML)
-
So,
South Africa was watching closely the failed effort in Massachusetts
to implement ODF? And now they are determined to make it work?Good
thing they left themselves a “pragmatic” out; “there are
standards which we are obliged to adopt for pragmatic reasons which
do not necessarily fully conform to being open in all
respects.”
Massachusetts
spent a full year on an ODF implementation Pilot Study only to come
to the inescapable conclusion that they couldn't implement ODF
without a high fidelity "round trip" capable ODF plug-in
for MSOffice. In May of 2006, Pilot Study in hand,
Massachusetts issued their now infamous RFi, "the Request for
Information" concerning the feasibility of an ODF plug-in clone
of the MS-OOXML Compatibility Pack plug-in for MSOffice applications.At the
time there was much gnashing of teeth and grinding of knuckles in the
ODf Community, but the facts were clear. The lead dog hauling the
ODf legislative mandate sleigh could not make it without ODf
interoperability with MSOffice. Meaning, the rip out and replace of
MSOffice was no longer an option. For Massachusetts to successfully
implement ODf, there had to be a high level of ODf compatibility with
existing MS documents, and ODf application interoperability with
existing MS applications.Although
ODf was not designed to meet these requirements, the challenge could
not have been any more clear. Changes in ODf would have to be made.So
what happened?
Over a year later, a few days after Sun
delivered their proprietary ODF plug-in for MSOffice, Massachusetts
announced that both ODF and MS-OOXML would be recognized as
implementable standards. (Good one Sun. Thanks a pant load.)
Recent legislative hearings in Texas concerning a bill that
would mandate ODF as the only document standard, revealed something
very surprising. There was direct testimony that out of the
entire Commonwealth of Massachusetts, only 24 desktops had
successfully transitioned to ODF. Whoops. Good thing they had the
Sun ODf plug-in :)
With Exchange/SharePoint developer
hubs going down everywhere, automagically converting binary
documents to MS-OOXML, and the MS-OOXML Compatibility Pack
plug-in effectively enabling workgroup conversions to MS-OOXML,
things do not look good for the future pragmatic
implementation of
ODF in Massachusetts. Or anywhere else for that matter.The
needed changes to ODf emphasizing the need to meet the Massachusetts
defined market requirements of high level of ODf compatibility with
existing MS documents, and ODf application interoperability with
existing MS applications, were not made by the OASIS ODf TC.
So
i wonder just how closely South Africa has been watching
Massachusetts?Not
that it's difficult to figure out. In Massachusetts it all came
down to the sprawl of MSOffice bound workgroups where business
process document
exchange
required this difficult "high fidelity round trip"
conversion. Not only does the ODF plug-in have to perfect a
consistently high fidelity conversion to ODF of these active
documents, but the documents had to be "round trip" ready
in terms of application use.
Round tripping is a killer for
ODf, with or without the inclusion of MSOffice desktops in any
workflow – document processing chain. The specification was
designed to protect content
during extensive document exchange and processing chain use, but not presentation!
During
an effective document exchange, many applications must be
interoperable at the file format level. For ODF this is limited
to "content",
with the assumption that each application will apply their own "presentation".
Sometimes this is jokingly called the "let
a thousand presentations bloom but don't touch my data"
approach. It's very consistent with the way document processing
experts view the world.
The "let
a thousand
presentations bloom"
approach is not however consistent with public expectations for ODF.
The public expects PDF quality of interop between
applications, where both content and presentation is preserved
throughout the document exchange process - unless and until the
owners of the document make changes.
This dilemma
brings us back to that age old problem of interactive (as opposed to
PDF static) document exchanges being totally tied to specific
applications - right down to the version level.What
we found in Massachusetts is that the ODf implementation barrier was
due to MSOffice bound workgroups and business processes. And it
wasn't just the year long Pilot Study screaming this. They gave us
150 test documents representative of critical business processes
where uncompromising fidelity had to be maintained. And yes, the
documents were filled with our favorite structural conversion
problems of lists, tables, fields, sections and page dynamics. These
problems in turn can be attributed directly to the structural
implementation differences between MSOffice and OpenOffice.
Let's
take this issue to a higher level. The ODF barrier itself had two
problem points which we've expresses as the critical market
requirements for a high level of ODf compatibility
with existing MS documents, and ODf application interoperability with existing MS
applications.The
first was that it's impossible to fully capture MSOffice feature sets
and specific structural implementation models in ODF. The ODf
container is simply not designed for the high fidelity conversion of
MS binary or xml documents, which directly reflect the MS application
specific implementation model of basic structures.Our
solution was the ODF iX "interoperability enhancements"
comprised of five generic elements for the structural basics of
lists, tables, fields, sections and page dynamics. These
extensions were critical to any ODF plug-in effort needing to
establish the high level of MSOffice compatibility - interoperability
demanded by Massachusetts workgroups wanting to transition to ODF.I
wonder if the South African workgroups are different? Maybe they
avoided the past ten years of MSOffice's dominance as a developer
platform? If that's the case, they can move directly to Linux
desktops running OpenOffice ODf. There would be no barrier similar
to what stopped Massachusetts, California, and the EU-IDABC.
The
ODF iX eXtensions were not acceptable to the OASIS ODF TC.
The
second problem point has to do with ODF Interoperability in general.
To be blunt, there is none. Except at the application specific
- version specific level of document exchange. And this is not
what the public expected from ODF.
To fix ODF
Interoperability, there has to be some level of compliance and
conformance requirements. Today, ODf compliance is optional.
Nor are there any test suite requirements, let alone anything as
strict and demanding as the W3C's "CDR" for W3C Compound
Document Formats.
Every ODF application has their own way of
implementing ODF. There are no guarantees of interop, or even
basic interop requirements.
Still, OpenOffice 2.3
workgroups can exchange documents effectively with other OOo 2.3
workgroups. Just don't try to exchange those same documents
with a Lotus Symphony desktop because Symphony is based on a
proprietary fork of OpenOffice 1.1.4.
The effect of
this is that a Lotus Symphony desktop (ODF 1.0) can't join a
OpenOffice 2.3 workgroup (which implements ODF 1.2) without seriously
disrupting the workflow.
Now imagine the situation in
Massachusetts where they expected OpenOffice ODF 1.0 desktops to be
joining ODF 1.0 plug-in enabled MSOffice workgroups! Or how
about Linux – OpenOffice desktops joining existing MSOffice
directed workgroups?To
compete against MS Server side systems, Linux server systems must
either figure out how to interoperate with the MSOffice – Outlook
bound workgroups, or, replace those desktops. Massachusetts sent
out a clear message; the disruptive cost of rip out and replace was
far beyond the price they were willing to pay for much desired
freedom to choose, freedom to innovate, and the sovereignty over
their information future that could have been theirs. And
Massachusetts understood, perhaps better than anyone, the value of
complete sovereignty. They couldn't bear the disruptive cost though.Compound
the matter with the reality that today, there are few if any ODF 1.0
- ISO 26300 applications, at any measure of compliance. Near
all have moved to some level of ODF 1.2.
Compound that
problem further by understanding that ODF 1.2, as currently written,
will not pass ISO certification. In May of 2006, ISO
Directorate issued a statement that ODF will not be exempt from ISO
Interoperability Requirements. The good news is that MS-OOXML also
fails to comply. But where does that leave the world?Confusion,
continuing ODf implementation – interoperability difficulties, and
the absence of a clear winner in the universal file format stakes
will leave the marketplace with only one option: the system default
provided by the MS Stack of MS-OOXML ready applications with
insidiously proprietary smart tags, XAML, WFP, TFS, and other stack
specific collections of dependencies.
This is the
interoperability thicket that South Africa so boldly charges into.
If the OASIS ODF TC, and the ODF community of applications do not get
there act together soon, odds are that South Africa will find
themselves in the same predicament as Massachusetts. All
dressed up in ODf with nowhere to go but MS-OOXML.
People have
accused us of overstating the ODF interoperability problems. The lord
of the garage gestapo and his minions insists that these
problems can be fixed. Let's hope they are right. Let's hope
that South Africa can pull off the implementation of ODF on something
more than 24 desktops. And let's hope that this time, the ODf
community comes out of the blogosphere and shows up for this
important implementation battle instead putting the entire burden on
SA as they did in Massachusetts.A few
more failures like Massachusetts and Microsoft is going to be
wondering why they ever went through the problems of submitting their
proprietary xml to ISO to begin with. Unless and until ODF can
successfully challenge MS-OOXML as a real world "implementable"
alternative, we're going to find ourselves stuck in the MS Stack for
years to come. ISO approval or not.~ge~
.
- garyedwards on 2007-10-28
-
That said, it goes on to acknowledge that “there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects.
Microsoft Partners with Atlassian & NewsGator - SharePoint Goes Web 2.0 - Flock
-
Pay close attention here boys and girls because here it is. Wonder why Microsoft is wealing, dealing and ready to shell out billions for Web 20 collaboration software? It's to tie them into the MS Stack of MSOffice, IE, Exchange/SharePoint, MS LIve, MS Dynamics, MS SQL Server, etc.
Grand convergence is the convergence of desktop, server, device and web systems. It increasing looks like were going to have to live with the MS Stack and the Open Stack of grand convergence interoperability. One will be able to have perfect interop within it's walls, with all applications able to handle the same compound XML document. The other will be totally unable to implement an inteoperable version of MS-OOXML.
Members of the MS Stack will be able to access everything in the Open Stacks, but outside systems will have limited (crippled) access into the MS Stack. Embrace, Extend, Extinguish. Here we go again.
~ge~
- garyedwards on 2007-10-20
-
4) Linking; Within Confluence, users can access SharePoint document facilities. By including SharePoint lists and content within Confluence, users can (in a single click) edit Microsoft Office documents.
Can't We All Just Get Along?
-
Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.
IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.
With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.
Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.
In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.
Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing documents, applications and processes to ODF.
The iX interoperability enhancement proposals are simplicity itself. There are only five generic elements that need to be added to the ODF spec to solve two of three real world problems holding ODF back. The five generics deal with the basic document structures of lists, fields, tables, sections and page dynamics (page breaks). These five structural elements account for almost all fidelity conversion problems between MS binaries, MS XML, and ODF.
So why would anyone oppose the inclusion of these proposals in ODF? Especially with Massachusetts, California, Denmark, Belgium and the EU-IDABC successful implementation of ODF hanging in the balance?
The answer is that neither Microsoft or Sun is willing to give up application control of their respective file formats. We all know that MS-OOXML is bound and strapped to the emerging Microsoft Stack of desktop, server, device and web applications. The surprise for many is that ODF is similarly bound and strapped to the OpenOffice/StarOffice desktop, with an added proviso that defies all pubic expectations; Sun insists that nothing goes into the ODf specification that isn't fully implemented and supported by OpenOffice.
Here's the kicker; it will take a major overhaul of the OpenOffice layout engine to implement the five generic iX elements. The iX interoperability enhancements are needed to solve real world problems now blocking the implementation of Odf.
What “real world” problems you might ask? Well, the world is not a clean slate. Most of the world's existing binary documents are bound to the MSOffice application platform. They are application specific/platform specific, and defy high fidelity conversion to any other application specific implementation model. Like that of OpenOffice.
Five years ago when the OASIS ODF effort began, we believed it was entirely possible to create a universal file format based on a highly portable XML document model. The needs of this universal file format were simple enough to enumerate. It had to be open, unencumbered, universally interoperable (reuse of open standards, open interfaces and open methods), and application-platform-vendor independent with an acceptable governance model.
We thought ODF could be that universal file format.
Five years later and we are nowhere near our goal of a universal file format capable of universal interoperability. The thing is, when a specification hits the real world, as ODF did in Massachusetts, the proof of it's universality, application independence and governance model is sorely tested. And ODF failed that test miserably.
Massachusetts had conducted a year long Pilot Study to determine how they could implement ODF. The final report led to the now infamous RFi - Request for Information about the feasibility of a ODF plug-in for MSOffice. Meaning, Massachusetts realized they could not implement ODF without having a ODF plug-in clone of the MS-OOXML plug-in for MSOffice. The disruption cost of rip out and replace alternatives to MSOffice was impossibly high. The problem being the incredible volumes of MSOffice bound workgroup-workflow business processes, line of business integrated applications, and assistive technology add-ons.
An XML plug-in for MSOffice enables a non disruptive and cost free transition of documents, applications and processes. Microsoft provides a plug-in for OOXML. So Massachusetts thought, why not one for ODf?
The problem with that question is this; ODf is bound to the OpenOffice specific layout and conversion engines. To implement ODf in MSOffice, some changes must be made to accommodate the MSOffice specific layout and feature set model. These changes were codified in the various ODf iX “interoperability enhancement” proposals submitted to the OASIS ODf membership for discussion. OpenOffice cannot implement or support the iX enhancements without significant changes to their layout engine and implementation model. End of story.
The Universal Document Challenge:
The iX “interoperability enhancement” issues are only one part of the impossible to implement ODf story. The other part is basic to any universal file format contender – the ability to solve three "real world" problems. Problems a universal file format must address because the world is not a clean slate:
.......Compatibility with existing documents - file formats :: including the volumes of MS binary documents.
...... Interoperability with existing applications :: including the over 500 million MSOffice bound workgroups.
.......Convergence of desktop, server, device, and web systems as fluid and highly interoperable routers of documents, data, and media.
First off, let's be clear that ODf is unable to solve any of the these problems. It was clearly not designed to address these issues. Not that they don't come up at the OASIS ODf TC. This is evidenced over the years by efforts to amend the ODf Charter to include compatibility with existing documents and interoperability with existing applications. Also there have been efforts to amend the infamous Section 1.5 “Compatibility – Conformance Clause” so that interoperability isn't an “optional” afterthought. And of course, there the iX proposals mentioned above.
Here's something to think about. Using the Microsoft OOXML plug-in for MSOffice, MS can solve all three problems. But that solution also locks business processes into the proprietary MS Stack of desktop, server, device and web applications and services. Locks them in for who knows how many years to come. So much so that, imho, this represents the most dramatic expansion of a convicted monopolist's power in history. Microsoft is making it's move from the desktop to the Internet, and taking everything in between.
ODf is not the target of Microsoft's OOXML-Smart Documents efforts!
Au contraire! Do not kid yourselves ..... HTML is the target! And the Internet the prize.
As for ODf? If ODf can't solve the three universal document challenges, it's not a threat to Microsoft.
Here's how it works. The core of the MS Stack is an alignment of MSOffice, IE, and the Exchange/SharePoint Developers Hub. From there, the MS Stack connects to a sprawl of applications including Active Directory, MS SQL Server, MS Dynamics, and MS Live. Everything in the MS Stack speaks fluent MS-OOXML-Smart Documents, and is able to access all proprietary dependencies found within the portable document. (Psst! MOOS docs are different than Ecma 376 docs in that MOOS docs are specific to MSOffice and bound through platform specific dependencies to the MS Stack)
Now pay close attention. MS-OOXML-Smart doc containers are designed for two things. First, to port document/data/media packages across the entire stack. There is no HTML or HTML+ here! Second, MOOS docs are a bridge to existing documents, applications and bound business processes that drive workgroups. Microsoft's emerging systems can of course integrate with existing workgroup-workflow processes, facilitating a massive migration of these processes from the current desktop interface to that of the Exchange/SharePoint Developer Hub.
So where are we at here? OpenDocument was designed for the “rip out and replace” of MSOffice, can't meet the universal file format challenge – was never designed for that, and there little interest amongst the OASIS masters for harmonization, convergence, or any kind of compatibility-interoperability with Microsoft products. MOOS docs were designed for the transition of existing workgroup-workflow business processes to the Exchange/SharePoint Hub, and the replacement of HTML as the primary language of the Internet. Ecma 376 does not have a non binding implementation worth spit. So what is the world left with?
The answer is HTML+. The surprise being that HTML+ can meet all three of our universal document challenges. Governance through the W3C and universal interoperability are of course, built into the DNA. Stay tuned. This battle is just beginning.
~ge~ - garyedwards on 2007-09-11
Selected Tags
Related Tags
Sponsored Links
Groups interested in ms-ooxml
Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »
Join Diigo
- garyedwards on 2007-10-29