Group Bookmarks tagged
You are here: Diigo Home > Groups > OpenDocument > Bookmarks > Group Bookmarks tagged iso,xml
Tags: din eu harmonization iso oasis odf ooxml xml on 01-29-2008 -Cached -About Shared by:Gary Edwards
more from www.oasis-open.org
Uh Oh. Microsoft and Novell joined the EU's call to harmonize ODF and OOXML, but Sun and IBM refused the invite. Now we have the invite in front of the OASIS ODF TC!. Is there any rock big enough for them to hide under if they also refuse?
And if the OASIS ODF does join the EU-DIN-ISO effort, where doe stha tleave IBM, Sun and their inistance on a politically mandated "rip out and replace" as the only acceptable solution?
Tags: archives iso odf ooxml xml on 01-27-2008 -Cached -About Shared by:Gary Edwards
more from www.oasis-open.org
Tags: cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml on 08-24-2007 -Cached -About Shared by:Gary Edwards
more from lists.oasis-open.org
Tags: iso odef odf ooxml openwave xhtml xml on 07-23-2007 -Cached -About Shared by:Gary Edwards
more from www.computerworld.com
There is nothing open about MOOXML, and it should have never made it to consideration as an international standard.
But one has to ask, what is up with Sun? The John Bosak comment is just as much cause for concern as the fact that the nations of the world would dare consider OOXML as an international standard. All i can say is that we've been had. Sun and Microsoft have worked us royally, and only now, at the last moment, does the fog of confusion clear and we can see it all.
Tags: gpl iso oasis odf ooxml xml on 07-12-2007 -Cached -About Shared by:Gary Edwards
more from docs.google.com
Tags: iso oasis odf officeopenxml ooxml opendocument xml on 06-29-2007 -Cached -About Shared by:Gary Edwards
more from www.consortiuminfo.org
MS XML-PDF Scope:The goal of the Technical Committee is to produce a formal
standard for office productivity applications within the Ecma
International standards process which is fully compatible with the
Office Open XML Formats. The aim is to enable the
implementation of the Office Open XML Formats by a wide set of tools
and platforms in order to foster interoperability across office
productivity applications and with line-of-business systems. The
Technical Committee will also be responsible for the ongoing
maintenance and evolution of the standard.Programme of Work: Produce
a formal standard for an XML-based electronic paper format and
XML-based page description language which is consistent with existing
implementations of the format called the XML Paper Specification,…[in each case, emphasis added]
If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, which constrained the TC as follows:Notice that the target in both charters is that of fostering interoperability across office productivity applications and with line-of-business systems.The goal of the Technical Committee is to produce a formal
standard for office productivity applications within the Ecma
International standards process which is fully compatible with the Office Open XML Formats.
The aim is to enable the implementation of the Office Open XML Formats
by a wide set of tools and platforms in order to foster
interoperability across office productivity applications and with
line-of-business systems. The Technical Committee will also be
responsible for the ongoing maintenance and evolution of the standard.[emphasis added]
It's beyond important that perople understand the nature of the MSOffice lock-in barriers that ODF and PDF must overcome. If our only problem was that of converting legacy MSOffice binary docuemnts to ODF or PDF, we would have broken the monopolist grip years ago.
What people have to realize is that it is the MSOffice bound workgroup-workflow business process barrier that is near impossible to overcome!
Let's go one step further and admit that Micrsoft's plugin approach for installing OOXML and XML-PDF in MSOffice is the only way to "realistically" overcome this business process barrier.
Which means there is an interesting corrollary for ODF. Only the internal ODF-PDF plugins for MSOffice will be able to similarly overcome the business process barrier. Rip out and replace approaches are too costly and disruptive. So much so that even in governments like Massachusetts, where they had mandated ODF, it has proved impossible to implement ODF.
One way of looking at this problem is to take the OASIS ODF big vendor blinders off and see clearly that the way Microsoft deals with the problem of converting existing documents and bound business processes to XML, is to provide their own OOXML :: XML-PDF plugin for existing MSOffice desktops.
Note well one other phenomenon confirming the efficacy of the plugin approach. The Microsoft - Novell deal resulted in a OOXML plugin for OpenOffice! Subsequent Micrsoft deals feature this highly controlled and directed version of "interoperability" through agreements with prominent LiNUX vendors tha tthey distribute the Novell OpenOffice version with the OOXML plugin set as the default file format!
The same ODF vendors who opposed an internal ODF Plugin for MSOffice, are now shipping an OpenOffice with the OOXML plugin set as default.
(With Sun is not far behind - from the document, "Interoperability Wars", we have this collection of gems:
.... Yes, Sun will, but not as a return favor. Sun is cooperating with
Novell on the OfficeOpenXML Translator plugin for OpenOffice, even
though they virulently opposed Novell's much needed "Interoperability
Enhancement" proposals on the OpenDocument Technical Committee. Sun
will focus on a high fidelity import of OfficeOpenXML into OpenOffice,
but most likely will put little if any effort into export. The old
one-way street trap that helped Microsoft to fame and fortune. Novell
is working on OOo export to OOXML.
Importing the beast...
Office Open XML Import Filter for Spreadsheets
OpenOffice Development at a Glance - Weekly Update & Schedule CW25 ....(notice all the scheduled work going into MS OfficeOpenXML import)
Roundtrip to Shanghai via Tokyo :: The Sun - Novell Joint Effort Import of OfficeOpenXML
New MS Word Filter for Writer (Milestone 1) :: Sun Beta of the OfficeOpenXML filter for OpenOffice
The OpenDocument Foundation's da Vinci pllugin for MSOffice is simply a clone of the Microsoft OOXML plugin (which is also called the XML Compatibility Kit :).
Interstingly, when Massachusetts was evaluating da Vinci, one of the priorities they asked for was that we focus on the PDF-ODF digital signature package. This is a design concept we presented to Massachusetts to include in da Vinci a PDF conversion. But not just any PDF conversion. What we proposed was to embed the ODF markup with the PDF file, implementing a digital signature to protect the ODF markup.
The PDF-ODF file could be opened in any Acrobat reader. This is a "static" view of the content. Or, if one had access to the digitally signed ODF markup, one could "interactively" access the contents using an ODF application. Including any da Vinci converted MSOffice workgroup-workflow bound desktop.
Now it appears that Microsoft is about to do the same thing with their OOXML :: XML-PDF plugin. Very cool, and much needed. But not something that can't also be done in ODF.
One area in his commentary where Andy makes a grave mistake is where he states:
#1This
seems to me to be a turning point for the creation of global
standards. Microsoft was invited to be part of the original ODF
Technical Committee in OASIS, and chose to stand aside. That committee
tried to do its best to make the standard work well with Office, but
was naturally limited in that endeavor by Microsoft's unwillingness to
cooperate. This, of course, made it easier for Microsoft to later claim
a need for OOXML to be adopted as a standard, in order to "better serve
its customers." The refusal by an incumbent to participate in an open
standards process is certainly its right, but it is hardly conduct that
should be rewarded by a global standards body charged with watching out
for the best interests of all.
This statement is absolutely true of the original OASIS ODF TC (Technical Committee) that first met in December of 2002. In fact, it was true throughout the first fifteen months of ODF TC activity. Everyone on that first TC group supported full interoperability with Microsoft applications and documents, except for one company - Sun.
There are three areas of "interoperability" that Sun opposed then, and continues to oppose today. The only difference being that after their 2004 deal with Microsoft, Sun has been uncompromisingly determined to block the interoperability the marketplace demands.
Prior to the 2004 deal, there is much evidence of interop flexibility that made it's way past Sun and into the ODF specification. It's not without good reason that the ODF 1.0 Conformance Section is also called the "universal generic".
The problem is that these interop holes in the ODF spec are "optional", and subsequently not supported or implemented by Sun's OpenOffice/StarOffice code base. In fact, almost anywhere you find "optional" implementation choices in ODF, most likely your starring at an interoperability break point.
Since the 2004 deal, the binding of ODF to Sun's OpenOffice/StarOffice feature set has hardened. So much so that after the failure of ODF in Massachusetts, CIO's across the nation started refering to ODF as having zero interop; a nice XML format that is impossible to implement in real world situations. A real world filled with situations dominated by MSOffice bound workgroup-workflow business processes.
Today the OASIS ODF TC is completly 180 degrees opposite the one that met in December of 2002.
There are three categories that define the "interoperability" problem:The CIO's who must deal with 15 years of MSOffice line of business development, need XML document solutions that can meet all three of the above interope criteria. The over riding problem for CIO's is that of migrating their documents and business processes to XML. The only question is, "Which XML, ODF or OOXML?
- Compatibility with existing file formats and documents
- Interoperability at the Application layer
- Convergence - the portability of an XML document across desktop, server, device and web information systems
So far ODF has been a no show. The only thing big ODF vendors have to offer is rip out and replace desktop alternatives to MSOffice. These are too costly and disruptive in terms of the bound business proceses to ever be considered, as evidenced by a year long ODF Pilot Study conducted by the Commonwealth of Massachusetts. A study that resulted in the Massachusetts Request for Information about the possibility of an ODF plugin for MSOffice. The Pilot Study was such a disaster for ODF that it was burried forever, never to see the light of day.
That leaves the entire future of ODF with the internal ODF plugins for MSOffice. An approach the big ODF do not support in either the marketplace, or, perhaps most importantly, at the level of the OASIS ODF TC - where "compatibility, interoperability and convergence" capabilites either go into the spec, or not.
Since 2004, it's been 100% NOT!
The proof of this can be seen in any number of OASIS ODF TC proposals and discussions. The most recent examples being threads having to deal with List Enhancement Proposals and Metadata XML/RDF.
The current membership of the OASIS ODF TC is clearly and unequivocably on record as opposed to the interoperability the marketplace is screaming for. The issues of "compatibility, interoperability, and convergence", as described above have been called by current TC members: "out of bounds", "out of scope", "not our problem", "let the converters and transformers deal with it", and "talk to Microsoft".
If Micrsoft were to join the OASIS ODF TC today, seeking to adapt ODF to meet the legacy document-MSOffice features-line of business integration needs of their monopoly base, the TC would have to deal with the exact same issues as they have summarily rejected with current compatibility-interoeprability-convergence disussions!
There is no possible way anyone can claim that today's OASIS ODF TC would welcome Microsoft and make accomodating changes to the specification! No way! And the proof of this hostility can be seen in the actual disussions and rejections of Micrsoft specific interoperability proposals.
Andy is out of touch and clearly drinking the kool-aid.
~ge~
Tags: iso linux odf ooxml open-source xml on 06-21-2007 -Cached -About Shared by:Gary Edwards
more from www.eweek.com
Tags: ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml on 06-19-2007 -Cached -About Shared by:Gary Edwards
more from fussnotes.typepad.com
"ECMA 376" is a set of file formats subject to ECMA and now to ISO.
"Office 2007" is a set of file formats which extend "ECMA 376" file formats.
Office 2007 file formats are undocumented per se. ECMA 376 are.
ECMA 376 file formats are documented but only at a syntactic level. To realize the true meaning of every single attribute is to realize that the documentation is more like 600,000 pages, not 6,000. Of particular difficulty is to keep some kind of control over the virtually infinite combinations of such attributes.
Quick analysis of the underlying schemas reveals that simple concepts such as text formatting is expressed in no less than 6 different and incompatible ways. This leads to thinking that the file formats were only designed to comply with existing legacy formats that themselves are the result of 15 years of inside/outside library aggregation (some of the libraries were bought from non-Microsoft vendors). In fact, the truth is, ask any reverse engineer third-party who worked with legacy formats, they'll tell you Microsoft essentially added angle brackets around the binary serialization in legacy formats. This makes for a very cool XML-based file format, not an international standard.
Tags: ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml on 06-19-2007 -Cached -About Shared by:Gary Edwards
more from talkback.zdnet.com
Tags: ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml on 06-19-2007 -Cached -About Shared by:Gary Edwards
more from www.betanews.com
By Marbux | posted Jun 19, 2007 - 3:16 PM |
Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy."
I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not.
I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf
Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.
Tags: california iso lai massachusetts oasis odf officeopenxml ooxml opendocument openxml xml on 06-09-2007 -Cached -About Shared by:Gary Edwards
more from www.computerworld.com
Tags: california davinci interop iso massachusetts oasis odef odf ooxml opendocument politics xml on 10-01-2007 -Cached -About Shared by:Gary Edwards
more from ec.europa.eu
Tags: california iso microsoft mooxml msoffice odf ooxml opendocument openxml xml on 03-20-2007 -Cached -About Shared by:Gary Edwards
more from www.computerworld.com
Tags: government iso microsoft odf ooxml vista xml on 03-13-2007 -Cached -About Shared by:Gary Edwards
more from docs.google.com
Tags: iso microsoft odf ooxml xml on 03-13-2007 -Cached -About Shared by:Gary Edwards
more from www.informationweek.com
