Skip to main content

Home/ Document Wars/ Group items tagged notes

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

AlphaDog Barks Loudly: Why Can't You Guys Just Get Along and Solve MY MSOffice Problem!... - 0 views

fussnotes.typepad.com/...going-to-bed-wi.html

alphadog cdf foundation hiser odf ooxml updegrove

shared by Gary Edwards on 12 Dec 07 - Cached
  • First, let me say that I am a CIO in a small (20 employees but growing fast) financial services company. I am well aware of how locked-in I am getting with our MS-only shop. I am trying to see my way out of it, but this "ODF vs ODFF" is leaving me very confused and no one is working to clear the fog. I beg for all parties to really work towards some sort of defined understanding. I don't need cooperation. But, what I don't have is well-defined positions from all parties. As it is, I feel safer staying the course with MS right now, honestly. It's what I know vs the mystery of this "open cloud" and all the bellicose infighting. How's that for "in the trenches" data? I posted a comment on Andy's blog, and I will post the same comment here for your group (minor edits): I will admit to being very, very confused by all of this ODF vs ODFF posturing. I will try to put my current thoughts in short form, but it will be a muddled mess. I warned you! From what I gather, the OpenDocument Foundation (ODFF) is attempting to create more of an interop format for working against a background MS server stack (Exchange/Sharepoint). You worry that MS is further cementing their business lock-in by moving more and more companies into dependency on not only the client-side software but also the MS business stack that has finally evolved into a serious competitive set. At that level, and in your view, the "atomic unit" is the whole document. The encoded content is not of immediate concern. ODF is concerned with the actual document content, which ODFF is prepared to ignore. The "atomic unit" is the bits and parts in the document. They want to break the proprietary encodings that MS has that lock people into MSOffice. The stack is not of any immediate concern. So, unless I misunderstand either camp, ODF is first attacking the client end of the stack, and ODFF is attacking the backbone server end of the stack. The former wants to break the MSOffice monopoly by allowing people to escape those proprietary encodings, and the latter wants to prevent the dependency on server software like Exchange and Sharepoint by allowing MS documents to travel to other destinations than MS "server" products. Is this correct? I have yet to see anyone summarize the differences in any non-partisan way, so I am at a loss and not enough information is forthcoming for me to see what's what. The usual diatribe by people closer to the action is to go into the history of ODF or ODFF, talk about old slights and lost fights, and somehow try to pull at emotional heartstrings so as to gain mindshare. Gary's set of comments on this blog have that flavor. This is childish on both sides. Furthermore, the word "orthogonal" comes to mind. I often see people too busy arguing their POV, and not listening to others, when there is no real argument to keep making. It's apple-and-oranges. ODF vs ODFF seems like they are caught in this trap. Everyone wants to win an argument that has no possible win because the participants are not arguing about the same thing. Tell me: Why can't the two parties get along? I can see a "cooperative" that attacks the entire stack. Am I the only one seeing this? Am I wrong? If yes, what's the fundamental difference that prevents cooperation?
  • Gary Edwards on 12 Dec 07
     
    AlphaDog When asked about the source of his incredible success, the hockey great Wayne Gretzky replied, "I skate to where the puck is going to be, not where it has been." You and i need to do the same. Let me state our position as this: The desktop office suite is where the puck has been. The Exchange/SharePoint Hub is where it's going to be. The E/S Hub is the core of an emerging Microsoft specific web platform which we've also called, the MS Stack. In this stack, MSOffice is relegated to the task of a rich client end user interface into the E/S Hub of business processes and collaborative computing connections. The rest of the MS Stack swirls like a galaxy of services around the E/S Hub. Key to Microsoft's web platform is the gradual movement of MSOffice bound business processes to the E/S Hub where they connect to the rest of the MS Stack. So what now you might ask? Some things to consider before we get down to brass tacks: ... There is a way to break the monopolists MSOffice desktop grip, but it's not a rip out and replace the desktop model. It's a beat them at the E/S Hub model that then opens up the desktop space. And opens it up totally. (this is a 3-5 year challenge though since it's a movement of currently bound business processes). ... It's all about the business processes. Focusing entirely on the file formats is to miss the big picture. ... The da Vinci group's position is this; we believe we can neutralize and re purpose MSOffice by converting in proce
Gary Edwards

IBM In Denial Over Lotus Notes - Forbes.com - 0 views

www.forbes.com/...cz_dl_0406notes.html

exchange ibm lotus microsoft

shared by Gary Edwards on 12 Dec 07 - Cached
  • The marketing folks in IBM's Lotus division are starting to sound like the Black Knight in Monty Python and the Holy Grail, who insists he's winning a fight even as he loses both arms and legs: "'Tis but a scratch," the Black Knight declares after one arm is lopped off. "Just a flesh wound," he says after losing the other. "I'm invincible!" The same goes for IBM's (nyse: IBM - news - people ) Lotus, which keeps declaring victory even as Microsoft (nasdaq: MSFT - news - people ) carves it up.
  • Gary Edwards on 12 Dec 07
     
    Want to know the real reason why IBM and Microsoft are going at it hammer and tong over document formats?  Here it is.  Lotus Notes is getting clobbered by the Exchange/SharePoint juggernaut. 

    The article is old, but the point is well taken.  Today the Exchange/SharePoint juggernaut i sover 65% marketshare.  IBM is struggling to protect the Lotus Stack against an impossible foe.

    The thing is, Microsoft E/S will ALWAYS have better integration with the MSOffice - Outlook desktop monopoly base (550 M and counting).  Most of this "integration" is due to the high fidelity exchange of documents in Microsoft's proprietary XML mode known as MS-OOXML.   Forget the charade that MS-OOXML is an open standard called Ecma 376.  MSOffice and infamous XML Compatibility Pack Plug-in do not implement Ecma 376.  The Pack implements MS-OOXML.

    One key differnece between MS-OOXML and Ecma 376 us that MS-OOXML is infused with the Smart Tags components.  These are for metadata, data binding, data extraction, workflow, intelligent routing and on demand re purposing of docuemnt components.  In effect, MS-OOXML :: Smart Tags combines with proprietary .NET Libraries, XAML and soon enough Silverlight to replace the entire span of W3C Open Internet Technologies. 

    Can you say "HTML"?

    Okay, so why does this matter to IBM and the future of Lotus Notes?

    The end game of the document format wars is that of a stack model that converges desktop, server, devices and web information systems.  The MS Stack uses MS-OOXML as the primary transport of accelerated content/data/multi media streams running across the MS Stack of desktop, server, device and web application systems.  It's the one point of extreme interoperability.

    It's also a barrier that no non MS applicatio or service can penetrate or interoperate with except on terms Microsoft dictates. 
Gary Edwards

XML Production Workflows? Start with the Web and XHTML - 0 views

quod.lib.umich.edu/...n-workflows-start-with-the-web

OpenWeb XML XHTML-CSS HTML5-CSS3-JavaScript IDML

shared by Gary Edwards on 07 Nov 13 - No Cached
  • Challenges: Some Ugly Truths The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition. Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper. A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition. And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5] But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.
  • Practical Challenges In 2009, there is still no truly likeable—let alone standard—editing and authoring software for XML. For many (myself included), the high-water mark here was Adobe’s FrameMaker, substantially developed by the late 1990s. With no substantial market for it, it is relegated today mostly to the tech writing industry, unavailable for the Mac, and just far enough afield from the kinds of tools we use today that its adoption represents a significant hurdle. And FrameMaker was the best of the breed; most of the other software in decent circulation are programmers’ tools—the sort of things that, as Michael Tamblyn pointed out, encourage editors to drink at their desks. The labour question represents a stumbling block as well. The skill-sets and mind-sets that effective XML editors need have limited overlap with those needed by literary and more traditional production editors. The need to think of documents as machine-readable databases is not something that comes naturally to folks steeped in literary culture. In combination with the sheer time and effort that rich tagging requires, many publishers simply outsource the tagging to India, drawing a division of labour that spans oceans, to put it mildly. Once you have XML content, then what do you do with it? How do you produce books from it? Presumably, you need to be able to produce print output as well as digital formats. But while the latter are new enough to be generally XML-friendly (e-book formats being largely XML based, for instance), there aren’t any straightforward, standard ways of moving XML content into the kind of print production environments we are used to seeing. This isn’t to say that there aren’t ways of getting print—even very high-quality print—output from XML, just that most of them involve replacing your prepress staff with Java programmers.
  • Why does this have to be so hard? It’s not that XML is new, or immature, or untested. Remember that the basics have been around, and in production, since the early 1980s at least. But we have to take account of a substantial and long-running cultural disconnect between traditional editorial and production processes (the ones most of us know intimately) and the ways computing people have approached things. Interestingly, this cultural divide looked rather different in the 1970s, when publishers were looking at how to move to digital typesetting. Back then, printers and software developers could speak the same language. But that was before the ascendancy of the Desktop Publishing paradigm, which computerized the publishing industry while at the same time isolating it culturally. Those of us who learned how to do things the Quark way or the Adobe way had little in common with people who programmed databases or document-management systems. Desktop publishing technology isolated us in a smooth, self-contained universe of toolbars, grid lines, and laser proofs. So, now that the reasons to get with this program, XML, loom large, how can we bridge this long-standing divide?
  • ...44 more annotations...
  • Using the Web as a Production Platform The answer, I think, is right in front of you. The bridge is the Web, a technology and platform that is fundamentally based on XML, and which many publishers are by now comfortably familiar with. Perhaps not entirely comfortably, but at least most publishers are already working with the Web; they already either know or have on staff people who understand it and can work with it. The foundation of our argument is this: rather than looking at jumping to XML in its full, industrial complexity, which seems to be what the O'Reilly-backed StartWithXML initiative[6] is suggesting, publishers instead leverage existing tools and technologies—starting with the Web—as a means of getting XML workflows in place. This means making small investments and working with known tools rather than spending tens of thousands of dollars on XML software and rarefied consultants. It means re-thinking how the existing pieces of the production toolchain fit together; re-thinking the existing roles of software components already in use. It means, fundamentally, taking the Web seriously as a content platform, rather than thinking of it as something you need to get content out to, somehow. If nothing else, the Web represents an opportunity to think about editorial and production from outside the shrink-wrapped Desktop Publishing paradigm.
  • Is the Web made of Real XML? At this point some predictable objections can be heard: wait a moment, the Web isn’t really made out of XML; the HTML that makes up most of the Web is at best the bastard child of SGML, and it is far too flaky/unstructured/underpowered to be taken seriously. We counter by arguing that although HTML on the Web exists in a staggering array of different incarnations, and that the majority of it is indeed an unstructured mess, this does not undermine the general principle that basic, ubiquitous Web technologies can make a solid platform for content management, editorial process, and production workflow.
  • With the advent of a published XML standard in the late 1990s came the W3C’s adoption of XHTML: the realization of the Web’s native content markup as a proper XML document type. Today, its acceptance is almost ubiquitous, even while the majority of actual content out there may not be strictly conforming. The more important point is that most contemporary Web software, from browsers to authoring tools to content management systems (from blogs to enterprise systems), are capable of working with clean, valid XHTML. Or, to put the argument the other way around, clean, valid XHTML content plays absolutely seamlessly with everything else on the Web.[7]
  • The objection which follows, then, will be that even if we grant that XHTML is a real XML document type, that it is underpowered for “serious” content because it is almost entirely presentation (formatting) oriented; it lacks any semantic depth. In XHTML, a paragraph is a paragraph is a paragraph, as opposed to a section or an epigraph or a summary.
  • n contrast, more “serious” XML document types like DocBook[8] or DITA-derived schemas[9] are capable of making semantic distinctions about content chunks at a fine level of granularity and with a high degree of specificity.
  • So there is an argument for recalling the 80:20 rule here. If XHTML can provide 80% of the value with just 20% of the investment, then what exactly is the business case for spending the other 80% to achieve that last 20% of value? We suspect the ratio is actually quite a bit steeper than 80:20 for most publishers.
  • IDML is a well thought-out XML standard that achieves two very different goals simultaneously: it preserves all of the information that InDesign needs to do what it does; and it is broken up in a way that makes it possible for mere mortals (or at least our Master of Publishing students) to work with it.
  • XHTML, on the other hand, is supported by a vast array of quotidian software, starting with the ubiquitous Web browser. For this very reason, XHTML is in fact employed as a component part of several more specialized document types (ONIX and ePub among them).
  • Why re-invent a general-purpose prose representation when XHTML already does the job?
  • It is worth pausing for a moment to consider the role of XHTML in the ePub standard for ebook content. An ePub file is, anatomically, a simply disguised zip archive. Inside the zip archive are a few standard component parts: there are specialized files that declare metadata about the book, and about the format of the book. And then there is the book’s content, represented in XHTML. An ePub book is a Web page in a wrapper.
  • To sum up the general argument: the Web as it already exists presents incredible value to publishers, as a platform for doing XML content management with existing (and often free) tools, and without having to go blindly into the unknown. At this point, we can offer a few design guidelines: prefer existing and/or ubiquitous tools over specialized ones wherever possible; prefer free software over proprietary systems where possible; prefer simple tools controlled and coordinated by human beings over fully automated (and therefore complex) systems; play to our strengths: use Web software for storing and managing content, use layout software for layout, and keep editors and production people in charge of their own domains.
  • Putting the Pieces Together: A Prototype
  • At the SFU Master of Publishing Program, we have been chipping away at this general line of thinking for a few years. Over that time, Web content management systems have been getting more and more sophisticated, all the while getting more streamlined and easier to use. (NB: if you have a blog, you have a Web content management system.) The Web is beginning to be recognized as a writing and editing environment used by millions of people. And the ways in which content is represented, stored, and exchanged online have become increasingly robust and standardized.
  • The missing piece of the puzzle has been print production: how can we move content from its malleable, fluid form on line into the kind of high-quality print production environments we’ve come to expect after two decades of Desktop Publishing?
  • Anyone who has tried to print Web content knows that the existing methods leave much to be desired (hyphenation and justification, for starters). In the absence of decent tools for this, most publishers quite naturally think of producing the print content first, and then think about how to get material onto the Web for various purposes. So we tend to export from Word, or from Adobe, as something of an afterthought.
  • While this sort of works, it isn’t elegant, and it completely ignores the considerable advantages of Web-based content management.
  • Content managed online is stored in one central location, accessible simultaneously to everyone in your firm, available anywhere you have an Internet connection, and usually exists in a much more fluid format than Word files. If only we could manage the editorial flow online, and then go to print formats at the end, instead of the other way around. At SFU, we made several attempts to make this work by way of the supposed “XML import” capabilities of various Desktop Publishing tools, without much success.[12]
  • In the winter of 2009, Adobe solved this part of the problem for us with the introduction of its Creative Suite 4. What CS4 offers is the option of a complete XML representation of an InDesign document: what Adobe calls IDML (InDesign Markup Language).
  • The IDML file format is—like ePub—a simply disguised zip archive that, when unpacked, reveals a cluster of XML files that represent all the different facets of an InDesign document: layout spreads, master pages, defined styles, colours, and of course, the content.
  • What this represented to us in concrete terms was the ability to take Web-based content and move it into InDesign in a straightforward way, thus bridging Web and print production environments using existing tools and skillsets, with a little added help from free software.
  • Such a workflow—beginning with the Web and exporting to print—is surely more in line with the way we will do business in the 21st century, where the Web is the default platform for reaching audiences, developing content, and putting the pieces together. It is time, we suggest, for publishers to re-orient their operations and start with the Web.
  • We would take clean XHTML content, transform it to IDML-marked content, and merge that with nicely designed templates in InDesign.
  • The result is an almost push-button publication workflow, which results in a nice, familiar InDesign document that fits straight into the way publishers actually do production.
  • Tracing the steps To begin with, we worked backwards, moving the book content back to clean XHTML.
  • The simplest method for this conversion—and if you want to create Web content, this is an excellent route—was to use Adobe’s “Export to Digital Editions” option, which creates an ePub file.
  • Recall that ePub is just XHTML in a wrapper, so within the ePub file was a relatively clean XHTML document. It was somewhat cleaner (that is, the XHTML tagging was simpler and less cluttered) than InDesign’s other Web-oriented exports, possibly because Digital Editions is a well understood target, compared with somebody’s website.
  • In order to achieve our target of clean XHTML, we needed to do some editing; the XHTML produced by InDesign’s “Digital Editions” export was presentation-oriented. For instance, bulleted list items were tagged as paragraphs, with a class attribute identifying them as list items. Using the search-and-replace function, we converted such structures to proper XHTML list and list-item elements. Our guiding principle was to make the XHTML as straightforward as possible, not dependent on any particular software to interpret it.
  • We broke the book’s content into individual chapter files; each chapter could then carry its own basic metadata, and the pages conveniently fit our Web content management system (which is actually just a wiki). We assembled a dynamically generated table of contents for the 12 chapters, and created a cover page. Essentially, the book was entirely Web-based at this point.
  • When the book chapters are viewed online, they are formatted via a CSS2 stylesheet that defines a main column for content as well as dedicating screen real estate for navigational elements. We then created a second template to render the content for exporting; this was essentially a bare-bones version of the book with no navigation and minimal styling. Pages (or even the entire book) can be exported (via the “Save As...” function in a Web browser) for use in either print production or ebook conversion. At this point, we required no skills beyond those of any decent Web designer.
  • Integrating with CS4 for Print Adobe’s IDML language defines elements specific to InDesign; there is nothing in the language that looks remotely like XHTML. So a mechanical transformation step is needed to convert the XHTML content into something InDesign can use. This is not as hard as it might seem.
  • Both XHTML and IDML are composed of straightforward, well-documented structures, and so transformation from one to the other is, as they say, “trivial.” We chose to use XSLT (Extensible Stylesheet Language Transforms) to do the work. XSLT is part of the overall XML specification, and thus is very well supported in a wide variety of tools. Our prototype used a scripting engine called xsltproc, a nearly ubiquitous piece of software that we found already installed as part of Mac OS X (contemporary Linux distributions also have this as a standard tool), though any XSLT processor would work.
  • In other words, we don’t need to buy InCopy, because we just replaced it with the Web. Our wiki is now plugged directly into our InDesign layout. It even automatically updates the InDesign document when the content changes. Credit is due at this point to Adobe: this integration is possible because of the open file format in the Creative Suite 4.
  • We wrote an XSLT transformation script[18] that converted the XHTML content from the Web into an InCopy ICML file. The script itself is less than 500 lines long, and was written and debugged over a period of about a week by amateurs (again, the people named at the start of this article). The script runs in a couple of seconds, and the resulting .icml file can then be “placed” directly into an InDesign template. The ICML file references an InDesign stylesheet, so the template file can be set up with a house-styled layout, master pages, and stylesheet definitions for paragraphs and character ranges.
  • The result is very simple and easy to use. Our demonstration requires that a production editor run the XSLT transformation script manually, but there is no reason why this couldn’t be built directly into the Web content management system so that exporting the content to print ran the transformation automatically. The resulting file would then be “placed” in InDesign and proofed.
  • It should be noted that the Book Publishing 1 proof-of-concept was artificially complex; we began with a book laid out in InDesign and ended up with a look-alike book laid out in InDesign. But next time—for instance, when we publish Book Publishing 2—we can begin the process with the content on the Web, and keep it there throughout the editorial process. The book’s content could potentially be written and edited entirely online, as Web content, and then automatically poured into an InDesign template at proof time. “Just in time,” as they say. This represents an entirely new way of thinking of book production. With a Web-first orientation, it makes little sense to think of the book as “in print” or “out of print”—the book is simply available, in the first place online; in the second place in derivative digital formats; and third, but really not much more difficult, in print-ready format, via the usual InDesign CS print production system publishers are already familiar with.
  • Creating Ebook Files Creating electronic versions from XHTML source is vastly simpler than trying to generate these out of the existing print process. The ePub version is extremely easy to generate; so is online marketing copy or excerpts for the Web, since the content begins life Web-native.
  • Since an ePub file is essentially XHTML content in a special wrapper, all that is required is that we properly “wrap” our XHTML content. Ideally, the content in an ePub file is broken into chapters (as ours was) and a table of contents file is generated in order to allow easy navigation within an ebook reader. We used Julian Smart’s free tool eCub[19] to simply and automatically generate the ePub wrapper and the table of contents. The only custom development we did was to create a CSS stylesheet for the ebook so that headings and paragraph indents looked the way we wanted. Starting with XHTML content, creating ePub is almost too easy.
  • today, we are able to put the process together using nothing but standard, relatively ubiquitous Web tools: the Web itself as an editing and content management environment, standard Web scripting tools for the conversion process, and the well-documented IDML file format to integrate the layout tool.
  • Our project demonstrates that Web technologies are indeed good enough to use in an XML-oriented workflow; more specialized and expensive options are not necessarily required. For massive-scale enterprise publishing, this approach may not offer enough flexibility, and the challenge of adding and extracting extra semantic richness may prove more trouble than it's worth.
  • But for smaller firms who are looking at the straightforward benefits of XML-based processes—single source publishing, online content and workflow management, open and accessible archive formats, greater online discoverability—here is a way forward.
  • Rather than a public-facing website, our system relies on the Web as a content management platform—of course a public face could easily be added.
  • The final piece of our puzzle, the ability to integrate print production, was made possible by Adobe's release of InDesign with an open XML file format. Since the Web's XHTML is also XML, is can be easily and confidently transformed to the InDesign format.
  • Furthermore, just to get technical for a moment, XHTML is extensible in a fairly straightforward way, through the common “class” attribute on each element. Web developers have long leveraged this kind of extensibility in the elaboration of “microformats” for semantic-web applications.[10] There is no reason why publishers shouldn’t think to use XHTML’s simple extensibility in a similar way for their own ends.
  • Using the Web as a Production Platform
  • Gary Edwards on 07 Nov 13
     
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
  • Gary Edwards on 07 Nov 13
     
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. As an after thought, i was thinking that an alternative title to this article might have been, "Working with Web as the Center of Everything".
  • Gary Edwards on 15 Nov 13
     
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format. My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS. Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff. My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to. The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML). The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF. Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML. Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
Gary Edwards

Open XML blogging in 2007 - Doug Mahugh - Site Home - MSDN Blogs - 0 views

blogs.msdn.com/...open-xml-blogging-in-2007.aspx

hypocrisy ODF odf-civil-war OOXML cloud-computing

shared by Gary Edwards on 22 Dec 10 - No Cached
  • Gary Edwards on 22 Dec 10
     
    At the height of the Document Wars, Doug Mahugh posted this year end, month to month, blow by blow list of blog assaults. I stumbled upon Doug's collection following up on a recent (December 20th, 2010) eMail comment from Karl.  Karl had been reading the infamous "Hypocrisy 101" blog written by Jesper Lundstocholm:  http://bit.ly/hgCVLV Recently i was researching cloud-computing, following the USA Federal Government dictate that cloud-computing initiatives should get top priority first-consideration for all government agency purchases.  The market is worth about $8 Billion, with Microsoft BPOS and Google Apps totally dominating contract decisions in the early going.  The loser looks to be IBM Lotus Notes since they seem to have held most of systems contracts. So what does this have to do with Hypocrisy 101? To stop Microsoft BPOS, IBM had to get a government mandate for ODF and NOT OOXML.  The reason is now clear.  Microsoft BPOS is dominating the early rounds of government cloud-computing contracts because BPOS is "compatible" with the legacy MSOffice desktop productivity environment.  Lotus symphony is not.  Nor is OpenOffice or any other ODF Office Suite.   This compatibility between BPOS and legacy MSOffice productivity environments means less disruption and re engineering of business process costs as governments make the generational shift from desktop "client/server" productivity to a Web productivity platform - otherwise known as "cloud-computing". IMHO, neither ODF or OOXML were designed for this cloud-computing :: Web productivity platform future.  The "Web" aspect of cloud-computing means that HTML-HTTP-JavaScript technologies will prevail in this new world of cloud-computing.  It's difficult, but not impossible, to convert ODF and OOXML to HTML+ (HTML5, CSS3, Canvas/SVG, JavaScript).  This broad difficulty means that cloud-computing does not have a highly compatible productivity authoring environment designed to meet the transition needs
Gary Edwards

Brian Jones: Open XML Formats : Office Open XML final draft!!! - 0 views

blogs.msdn.com/...final-draft_210021002100_.aspx

drawingml eooxml imported:del.icio.us msoffice odf vml xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • # re: Office Open XML final draft!!! @ Wednesday, October 11, 2006 1:46 PM The past incarnations of DrawingML have been chaotic. It would be interesting, out of curiosity, to get an accurate history of what changed over time, perhaps to better understand what is supported in what. Here is my take, I am pretty sure I got at least 50% of it wrong :-) - pre-Windows 95 era, Word, Excel and Powerpoint use their own vector drawing layer used to draw shapes, pictures, diagrams, art and charts. Powerpoint, acquired by Microsoft in 1987, has by far the advanced drawing layer (bi-linear gradients, opacity, ...), codenamed Escher (in reference of the famous mathematician). - In Office 95, it is decided to reuse the Powerpoint vector graphics layer in Word and Excel. Migration begins. - Migration ends with Office 97 where both Word, Excel and Powerpoint use the same vector graphics layer, publicly known as MSO (mso97.dll) - In Office 2000, it's all craze about internet and Word tries to export WYSIWYG html. For that end, mark up extensions must be added to account for the MSO drawing layer. Hence the VML (Vector Markup language). Excel and Powerpoint don't support it. Internet Explorer natively supports VML (Internet Explorer's Direct animation vector drawing layer dismissed for performance reasons). - In Office XP, VML migration ends and both Word, Excel and Powerpoint support VML whenever a document is saved as a "Single web page archive" (.mhtml extension). - In Office 2003, nothing changes. - In Office 12, MSO gets rewritten with backwards compatibility in mind. The vector drawing layer uses more sophisticated drawing functionalities which makes it easier to draw themed, 3D realistic  objects. Technically, the differences are akin to the differences between GDI and GDI+. This new shared library is known as E2O and the corresponding mark up language is known as Drawing ML (Ecma TC45 specs). - In Office 14, ??? perhaps the drawing layer is rewritten, again, to 1) use WPF 2) to allow plugins, hence enabling much more sophisticated do-it-yourself scenarios. Use cases : custom charts ; BI analysis tools. Stephane Rodriguez
  • Gary Edwards on 12 Dec 07
     
    Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
  • Gary Edwards on 12 Dec 07
     
    Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
  • Gary Edwards on 12 Dec 07
     
    Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
Gary Edwards

Cutting corners - the realpolitik of ODF standardisation? - The Wayback Machine Roars R... - 0 views

notes2self.net/...446.aspx

odf interoperability james-clark oasis

shared by Gary Edwards on 08 May 09 - Cached
  • Gary Edwards on 08 May 09
     
    From Notes2Self 2006 post we discover once again that ODF Interop problems are not new. Back in early February 2005, top ranking OASIS Executive James Clark made a comment to the OASIS OpenDocument technical Committee about the lack of interoperability for spreadsheet documents:

    ".... I really hope I'm missing something, because, frankly, I'm speechless.  You cannot be serious. You have virtually zero interoperability for spreadsheet documents. OpenDocument has the potential to be extraodinarily valuable and important standard. I urge you not to throw away a huge part of that potential by leaving such a gaping hole in your specification...". Claus Agerskov further commented that this provided a means of creating lock-in (my emphasis)

    "OpenDocument doesn't specify the formulars used in spreadsheets so every spreadsheet vendor can implement formulars in their own way without being an open standard. This way a vendor can create lock-in to their spreadsheets"
Gary Edwards

But can money buy love? :: Another Microsoft Sponsored OOXML Study - 0 views

www.microsoft-watch.com/...fts_sponsored_ooxml_study.html

cdf interoperability ms-xml odf officeopenxml ooxml opendocument vista-stack

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    Joe Wilson of Microsoft Watch knocks another one out of the park. Why is it that so few in the media get it? Or anyone else for that matter? Matt Assay gets it. But few understand the Vista Stack and the importance of OOXML in the transition of the monopoly base from MSOffice to the Vista Stack. No doubt the arrogance of those who dare challenge Microsoft is both a necessary blessing and guaranteed curse. Take for instance the widely held assumption that Microsoft invented MS-XML (OfficeOpenXML) in response to OpenDocument (ODf). This is false, misleading and will inevitably result in a FOSS death spiral in the face of a Vista Stack juggernaut. But it sure does feel good.

    Joe Wilson at Microsoft Watch points out the real reason for MS-XML, and why ISO approval of OOXML is so important. Microsoft needs OOXML approved as an international standard because OOXML is the binding model for the emerging Vista Stack of loosely coupled but information integrated applications.

    The Vista Stack model converges desktop, server, device and web information systems using OOXML-Smart Documents, .NET 3.0 and the XAML presentation layer as the binding components.

    The challenge for Microsoft is to migrate existing MSOffice bound business processes, line of business integrated apps, and advanced add-ons to the Exchange/SharePoint Hub. Once the existing documents, applications (MSOffice) and processes are migrated to the E/S Hub, they can be bound tightly to the rest of the Vista Stack.

    Others see OOXML as some sort of surrender or late recognition that the salad days of MSOffice are over. They jubilantly point to Web 2.0, Office 2.0 and rise of the LiNUX Desktop as having ushered in this end of monopoly for MSOffice. Like the ODf champions, these people are similarly sadly mistaken!

    While they celebrate, Microsoft is quie
Gary Edwards

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views

www.microsoft-watch.com/...obla_de_oba_da.html

odef odf officeopenxml ooxml opendocument vista-stack

shared by Gary Edwards on 12 Dec 07 - Cached
  • To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.

      The binding model for OOXML is "Smart Documents", and it is proprietary!

      Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.

      Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.

      Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.

      I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.

       Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.

      One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.

      This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
  • Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      The vertical stack is actually desktop - server - device - web based.  The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.

      Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement.  One of the primary failings of ODF is that it is not able to be fully implemented in this converged space.  OOXML on the other hand was created exactly for this purpose!

      So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets.  OOXML differs in that it is tightly bound to the Vista Stack.

      So where is an Open Stack model to turn to?

      Good question, and one that will come to haunt us for years to come.  Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.

      OOXML is unfi as a UFF becuase it is application - platform and vendor bound.

      For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.

      XHTML+ (XHTML + CSS3 + RDF) is looking very good.  The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML+.  Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML+?

      I think so.  But we can't be sure until the da Vinci proves this conclusively.

      One thign to keep in mind though.  The internal plugins have already shown that it is possible to do multiple file formats.  OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.

      So why not try it with XHTML+, or ODEF (the eXtended version of ODF en
  • Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be.  ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.

      The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice,  does not fully support and implement the Conformance Clause. 

      The only foreign elements supported by OpenOffice are paragraphs and text spans.  Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!

      This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.

      Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci.  KOffice ODF and Googel Docs ODF are all different ODF implementations.  Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.

      It's also true that OOXML has optional implementation areas.  With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange  presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.

      With OOXML, the entire Vista Stack - Win32 dependency layer is "optional".  No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies.    This includes the legacy Win32 API dependencies (like VML, EMF, EMF +), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.

      MSOffice 2007 i
  • ...6 more annotations...
  • Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      True, but a tricky statement given that the proprietary OOXML implementation is "optional".  It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".

      In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.

      Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!

      It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.

      So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat.  For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true.  For all practical concerns, that's enough.  For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.


  • Microsoft got there first to protect Office.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!

      Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.

      The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.

      The Vista Stack looks like this:

      ..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub

      ..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End

      The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.

      The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.

      The productivity gains that can be had through this migration to the E/S Hub are extraordinary.

      A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)

      These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital".  For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model.  This will no doubt change with the emer
  • Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      Okay, now Joe has the Micrsoft SOA bull by the horns.  Why doesn't he wrestle the monster down?
  • By adapting XML
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!

      In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.

      Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.

      Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.

      Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.

      When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!

      The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.

      Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
  • Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

      What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.

      Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
  • I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.

      The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality.  Which, for the sake of brevity we can call the lead Win32 API dependencies.

      One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.

      Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration.  As long as the complete Win32 API was available (Windows + MSOffice + VBA run times), this platform was great for workgroups.  The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.

      The Internet offers everyone a new way of integrating data, content and streaming media.  Web applications are capable of loosly coupled serving and consuming of other application services.  Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.

      On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.

      Into this SOA mash Microsoft will push with a sweeping integrated stack model.  Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.

Gary Edwards

ODF Split: Good Riddance, Good Grief, or Game Over? Michael Desmond Redmond Developer ... - 0 views

reddevnews.com/...weblog.aspx

cdf foundation odf ooxml opendocument

shared by Gary Edwards on 13 Dec 07 - Cached
  • Gary Edwards on 13 Dec 07
     
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
  • Gary Edwards on 13 Dec 07
     
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
Gary Edwards

CDI WICD 2.0 - 0 views

www.w3.org/...Overview.html

cdf css svg w3c wicd xforms xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • This document defines a generic language-independent processing model for combining arbitrary document formats. The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, together with CSS and the DOM; it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats. 1.1. Conformance Everying in this specification is normative except for diagrams, examples, notes and sections marked non-normative. The key words must, must not, required, shall, shall not, should, should not, recommended, may and optional in this document are to be interpreted as described in RFC 2119 [RFC2119]. This specification defines the following classes of products: conforming implementation A user agent that implements all interfaces described in this specification and follows all must-, required- and shall-level of critera in this specification. conforming document A document that follows all must-, required- and shall-level of critera in this specification that apply to document authors. conforming authoring tool One that produces conforming documents.
Gary Edwards

Notes on Breaking the Web to Ride the Fifth Wave - 1 views

community.zdnet.co.uk/...,1000000565,2000542666b,00.htm

ie-8 iso microsoft msoffice odf ooxml sdk xaml

shared by Gary Edwards on 22 Mar 08 - Cached
  • garyedwards's Discussions Breaking the Web Talkback: Google: OOXML 'insufficient and unnecessary'
  • Gary Edwards on 22 Mar 08
     
    Somehow i got involved in this discussion and ended up posting a number of comments explaining the how and why behind Microsoft's push for ISO approval of MS-OOXML. I have been working on a paper titled, "Breaking the Web to Ride the Great Wave". Breaking the Web is what will happen once ISO approves MS-OOXML. The MIcrosoft Stack of Web Servers (Exchange, SharePoint, MS-SQL Server) are integrated into the MSOffice-Outlook desktop. The MS desktop dominates much of the document workflows and business processes of the commercial world. ISO approval of the MSOffice specific MS-OOXML will legitamize MSOffice as an editor of standardized web ready docuemnts. But how MS-OOXML docuemnts become "Web REady" is tricky. In the December 2007 MSOffice SDK beta, we see how this is done. The SDK provides a conversion component for the quick high fidelity conversion of MS-OOXML documents to XAML. XAML is a proprietary part of the WPF (Windows Presentation Foundation) layer of the .NET framework, and is easily paried with Silverlight. Sometimes XAML is referred to as "fixed/flow". XAML is an MS proprietary replacement for the W3C's (X)HTML. Billions of MSOffice docuemnts will make their way to the Web using this SDK converter. The path for transitioning the monopolist hold on desktop business processes to the monopolist stack of web servers is set with this converter. ISO approval of MS-OOXML will enable Microsoft to dodge brining their desktop editor into compliance with advancing W3C standards such as (X)HTML, CSS 3, XForms, SVG and RDF. Instead of these open standards, transitioning business processes will be locked into MS only dependencies; XAML, Silverlight, WinForms, and Smart Tags. The breaking of the web results in a consumer/business cloud dependent on MS proprietary technologies that are out of the reach of Firefox, Apache, Java, and Adobe technologies. Google won't be able to penetrate the business stack, and will be kept very busy trying to defen
Gary Edwards

IBM's Director of Strategy comes clean on OpenXML - IBM *WILL* support OpenXML in its L... - 0 views

notes2self.net/...lotus-and-portal-products.aspx

cdf heintzman ibm odf ooxml openxml

shared by Gary Edwards on 25 Jan 08 - Cached
  • Well, if that's IBM's plan they're going to need more than ODF, that's for sure - and that brings us to the announcement I've been wondering about: IBM favors ODF as a file format because it is "truly open" and technically elegant, Heintzman said. But IBM will support Open XML, which is the current document format in Office 2007, in its Lotus collaboration and portal products. IBM already supports older versions of Office. I feel a Pamela Jones moment coming on .... there it is, as plain as day for the world to see, Doug Heintzman breaks through all IBM's doublespeak and hypocrisy and admits it. I don't know about "Beyond Office" as a plan, I think the real game here is "Beyond ODF"
Graham Perrin

Doug Mahugh : Standards-Based Interoperability - 0 views

blogs.msdn.com/...ds-based-interoperability.aspx

interop standard ODF OOXML Excel spreadsheet OpenFormula

shared by Graham Perrin on 28 Jul 09 - Cached
  • Standards-Based Interoperability
  • 05 June 09
  • Interoperability without Standards
  • ...46 more annotations...
  • First, let’s consider how software interoperability works when it is not standards-based. Consider the various ways that four applications can share data, as shown in the diagram to the right.&nbsp; There are six connections between these four applications, and each connection can be traversed in either direction, so there are 12 total types of interoperability involved.
  • As the number of applications increases, this complexity grows rapidly.&nbsp; Double the number of applications to 8 total, and there will be 56 types of interoperability between them:
  • through standards maintenance, transparency of implementation details, and collaborative interoperability testing.
    • Graham Perrin
      Graham Perrin on 28 Jul 09
       
      Issues relating to CalDAV are well addressed in these ways.
  • Here’s where those workarounds will need to be implemented: Note the complexity of this diagram.
  • In the real world, interoperability is almost never achieved in this way.&nbsp; Standards-based interoperability is much better approach for everyone involved,
  • whether that standard is an open one such as ODF (IS26300)
  • or a de-facto standard set by one popular implementation.
  • or Open XML (IS29500)
  • The core premise of open standards-based interoperability is this:
  • each application implements the published standard as written, and this provides a baseline for delivering interoperability.
  • the existence of a standard addresses many of the issues involved, and the other issues can be addressed
  • In the standards-based scenario, the standard itself is the central mechanism for enabling interoperability between implementations: This diagram is much simpler
  • there is no question that users of other products are massively surprised by
  • How this all applies to Office 2007 SP2 I covered last summer the set of guiding principles that we used to guide the work we did to support ODF in Office 2007 SP2.
  • applied in a specific order
  • I’d like to revisit the top two guiding principles
  • Guiding Principle #1: Adhere to the ODF 1.1 Standard
  • Guiding Principle #2: Be Predictable
  • Being predictable is also known as the principle of least astonishment.
  • What about Bugs and Deviations? Of course, the existence of a published standard doesn’t prevent interoperability bugs from occurring.
  • deviations from the requirements
  • different interpretations
  • Our approach to the transparency issue has been to document the details of our implementation through published implementer notes.
  • Interoperability Testing The final piece of the puzzle is hands-on testing
  • What else would you like to know about how Office approaches document format interoperability?
  • a standard (evolved and improved as reality demands) is the proper foundation for resolving interoperabilty
  • All complex software has bugs, and some bugs can present significant challenges to interoperability.&nbsp; Let’s consider the case that 3 of the 4 applications have bugs that affect interoperability, as shown in the diagram to the right.
  • (1) their spreadsheets having their formulas lost when interchanged with Excel 2007
  • (2) not being able to handle the formulase received in Excel 2007's ODF output.
  • I am creating my own fantasy about the state of affairs
    • Graham Perrin
      Graham Perrin on 28 Jul 09
       
      :-)
  • it is far too early to declare it to be unsuccessful
  • I cannot fault the Microsoft approach as incorrect
  • I was at the year-ago DII meeting where the guiding principles were announced and their application to spreadsheet formulas described. &nbsp;I applauded the principles and understood the reasoning for formulas.
  • How this would impact various groups of users and non-users (who still want to interoperate) of Office 2007 did not surface in my consciousness.
  • there is NO published standard for ODF spreadsheet formulas yet.
  • Nor is there any de-facto standard that everyone agrees on.
  • the “spaghetti diagram" method, with all of the complexity and risk of bugs that entails
  • No implementer we know of has attempted that
  • In the case of spreadsheet formulas, help is on the way -- OpenFormula is under development for use with ODF 1.2.
  • I’d like to keep this thread on-topic
  • I appreciate the post, very good
  • Visually I would rather frame it in terms of convergence, a spiral.
  • and user satisfaction.
  • I doubt someone would ever find a magic bullet to interoperability
  • New Comments to this post are disabled
    • Graham Perrin
      Graham Perrin on 28 Jul 09
       
      Hurrah!
  • © 2009 Microsoft Corporation
  • Graham Perrin on 28 Jul 09
     
    Diagrams here are eye-catching.
Gary Edwards

OASIS ODF: List Proposal Enhancement Vote Deadline on Wednesday | Gary Edwards - 0 views

lists.oasis-open.org/...msg00001.html

odf openxml oasis list-enhancement

shared by Gary Edwards on 04 Jun 09 - Cached
  • Gary Edwards on 04 Jun 09
     
    Thanks to Paul for digging this up. Who would have guessed that years later, these same issues hang like a dark shroud on the future of ODF? Note also that June 1st of 2007 was the cut off date for ODF 1.2 proposals and recommendations. The OpenFormula and Metadata SC's were rushing to make the cutoff. The List Enhancement proposal itself was just one of many enhancements submitted by Florian Reuter in November of 2006, designed to greatly improve ODF compatibility with MSOffice "ODF". By November of 2006, thanks largely to the Massachusetts Pilot Study, there were a number of ODF plug-ins for MSOffice. All were capable of producing perfectly compliant ISO 26300 ODF, but falling far short of public expectations of high fidelity interop with OpenOffice ODF. Sound familiar? Everyone knew that it was only a matter of time before Microsoft was pressed into providing MSOffice ODF support. There was no doubt that they would face the exact same interop challenges as the many independent plug-in efforts. Hence the stepped up efforts by many at the OASIS ODF to "fix" ISO 26300! At the time of the List Enhancement Proposal, we had increasing evidence from the many pilot studies that ODF was impossible to implement in business and workgroup environments where the MSOffice productivity environment was the defining platform. ODF was not designed to be compatible with MSOffice or the binary documents so critical to business processes bound to this environment. OpenXML was designed exactly to be compatible with these environments. Unless ODF fixed it's compatibility/interoperability problems there was no way for the independent plug-ins to provide a reasonable ODF implementation alternative to OpenXML. And even if Microsoft did produce an MSOffice ODF compliant with ISO 26300, these productivity environments would remain entirely locked. The world expected ODF to be compatible, interoperable, Web ready, and fully capable of cracking open the iron grip Mic
Graham Perrin

Where is there an end of it? | Notes on Document Conformance and Portability #3 - 0 views

www.adjb.net/...ormance-and-Portability-3.aspx

shared by Graham Perrin on 13 May 09 - Cached
  • a calm look at some of the issues
    • Graham Perrin
      Graham Perrin on 13 May 09
       
      Still, not all of the subsequent comments are calm…
  • Microsoft’s implementation decision
  • an implementation of ODF which does not interoperate with other available implementations
  • ...21 more annotations...
  • on the face of it
  • some real problems with basic spreadsheet interoperability among ODF products using undocumented extensions
  • abandoning the “convention”
  • these ODF implementations have limited interoperability
  • more or less
  • unsafe for any mission-critical data
  • ODF implementations can actually cut it,
  • legacy support as an option
  • this interoperability fiasco has been allowed to happen within the context of a standard
  • in the interests of the users
  • behave better
  • good news
  • work is underway to fix this problem: ODF 1.2
  • people may disagree in good faith
  • does not, in fact, conform
  • Rob’s statement that “SP2's implementation
  • is mistaken on this point
  • no grounds for complacency about the sufficiency of the ODF specification
  • keen to see defects, such as conformance loopholes, fixed in the next published ODF standard
  • I urge all other true supporters to read the drafts and give feedback to make ODF better for the benefit of everyone
  • Microsoft is the only one of seven main ODF implementations that fail to achieve interoperability in ODF formulas
Gary Edwards

Patent Ruling Against Microsoft Hinges on Meaning of Custom XML - 0 views

www.eweek.com/...n-Meaning-of-Custom-XML-594907

i4i 449-patent MSWord custom-xml

shared by Gary Edwards on 21 Aug 09 - Cached
  • Gary Edwards on 21 Aug 09
     
    Marbux discovered this gem, joining the argument with an insightful but disagreeing post.  I however agreed with the articles author, Jeff Cogswell, that both the judge and jury confused the XML pane feature set with metacode mapping claims in the now infamous i4i 449 patent.  If Marbux is right, then HTML-CSS, ODF, and RDF/XML-RDFa are also infringing on this patent.  Which i4i claims is not the case. Except: Here's one part of the ruling:  ...  Microsoft Corporation is hereby permanently enjoined from ... selling, offering to sell ... any Infringing and Future Word Products that have the capability of opening a .XML, .DOCX, or .DOCM file ("an XML file") containing custom XML. The odd wording here is "custom XML," which appears several times in the ruling. Based on the comments in response to eWEEK's articles on the ruling, as well as comments I've seen elsewhere, a great deal of people think the problem was that Microsoft uses XML as its format. But that isn't the case. The ruling focuses on the use of custom XML. The ruling is not about the fact that Word uses XML. If it did, there would be a worldwide disaster, considering how prevalent XML is. But what exactly is custom XML? To start with, let's look at the claims of the patent itself and try to make a connection. The patent, which was written back in 1994, covers a new way of providing formatting in a word processing program. To understand the claims of the patent, it's important to note the distinction between what the inventors call content and what are called metacodes (which are ultimately formatting codes).
Gary Edwards

No REST in CMIS » Untangled by Roy Fielding - 0 views

roy.gbiv.com/...no-rest-in-cmis

RESt CMIS document-models Sursen

shared by Gary Edwards on 29 Dec 10 - No Cached
  • Gary Edwards on 29 Dec 10
     
    REST creator Roy Fielding weighs in on CMIS, the Content Management Interoperability Services standard proposed by pay-to-play OASIS members and big RDBMS vendors; EMC, IBM and Microsoft.  Note, Roy works for Day Software, which has been acquired by Adobe. The CMIS proposal is suspiciously similar to the Sursen UOML OASIS Standard that ISO rejected!!!  excerpt: CMIS is a thin veneer on RDBMS-based data repositories that provides a data model for document-like objects within filesystem-like folders, basic file versioning, and access via SQL queries and local object references. It is exactly the kind of document model one would expect within a legacy document management system that is backed by a large relational database and authored via Microsoft Office applications. No surprise, given the sponsors, and there are plenty of good reasons why folks would want to support such data models.
Gary Edwards

Florian - libopc libreoffice - 0 views

www.youtube.com/watch

LibOPC LibreOffice

shared by Gary Edwards on 26 May 11 - No Cached
  • Gary Edwards on 26 May 11
     
    Florian is back with another YouTube video.  This time demonstrating the wonders of ODF, using his LibOPC library to pump ODF into MSWord.  He demonstrates using the LibOPC library to make direct changes to the ODF document that are perfectly reflected in LibreOffice and MSWord, with some noted exceptions.  all of which are carefully explained and visually demonstrated.  Once again, a nice job by Florian.
Gary Edwards

Microsoft attacks UK government decision to adopt ODF for document formats - 0 views

www.computerweekly.com/...adopt-ODF-for-document-formats

ODF Microsoft

shared by Gary Edwards on 23 Jul 14 - No Cached
  • the panel reached consensus that one standard is important to ensure interoperability and to allow users to collaborate effectively on the same document,” said the minutes
  • A subsequent meeting of the same panel also considered a detailed comparison of ODF and OOXML, citing concerns raised by one member. “We need to make sure there is sound reasoning to back up the decision as this may incur significant costs to some government departments. The comparison may be slightly skewed by concentrating solely on implementation of strict OOXML, which is an emerging standard similar to ODF 1.3, whilst considering implementations of all ODF versions. It ignores transitional OOXML which does have very wide support, arguably wider than ODF,” said the meeting minutes.
  • “LH described the issues identified in the [comparison] document and added that there has since been some confusion about support for OOXML strict in LibreOffice.&nbsp; It appears that LibreOffice supports the standardised transitional OOXML, as well as a different Microsoft version of transitional OOXML,” the minutes stated.
  • ...3 more annotations...
  • Despite its obvious disappointment at the government’s decision, Microsoft was also keen to point out that its software does fully support ODF.
  • “The good news for Office users is that Office 365 and Office 2013 both have excellent support for the ODF file format, so their current and future investments in Office are safe.&nbsp; In fact, Office 365 remains the only business productivity suite on the UK government’s G-Cloud that is accredited to the government’s own security classification of 'Official' and which also supports ODF,” said the Microsoft spokesman.
  • Government Digital Service director Mike Bracken
  • Gary Edwards on 23 Jul 14
     
    "Microsoft has attacked the UK government's decision to adopt ODF as its standard document format, saying it is "unclear" how UK citizens will benefit. The Cabinet Office announced its new policy yesterday, whereby Open Document Format (ODF) is immediately established as the standard for sharing documents across the public sector, with PDF and HTML also acceptable when viewing documents. SERGIGN - FOTOLIA The decision was a rejection of Microsoft's preference for Open XML (OOXML), the standard used by its Word software, which remains the dominant wordprocessor in government. "Microsoft notes the government's decision to restrict its support of the file formats it uses for sharing and collaboration to just ODF and HTML," said a spokesman for the software giant in a statement to Computer Weekly. "Microsoft believes it is unproven and unclear how UK citizens will benefit from the government's decision. We actively support a broad range of open standards, which is why, like Adobe has with the PDF file format, we now collaborate with many contributors to maintain the Open XML file format through independent and international standards bodies," it added"
Gary Edwards

ODF1.2 Interoperability Proposal - 0 views

www.oasis-open.org/...msg00048.html

california compatibility davinci interoperability iso massachusetts oasis odf officeopenxml ooxml opendocument openxml plugin xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • Subject: Suggested ODF1.2 items From: "Florian Reuter" &lt;freuter@novell.com&gt; To: &lt;office@lists.oasis-open.org&gt; Date: Mon, 20 Nov 2006 17:03:24 +0100 Suggested enhancement for OpenDocument V1.2
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      This message was submitted to the ODF-OOo/SO OASIS TC the day Florian joined Novell. His Novell contract allowed him to continue his work as the OpenDcoument Foundation's CTO. Take note of the response from Sun's Michael Brauer. It's a classic. The link is at the bottom of the page. ~ge~
  • Gary Edwards on 12 Dec 07
     
    Part of the sad but enduring "History of Failed ODF Interoperability Attempts".  This particular message is dated November 20th, 2006. 

    The OpenDocument Foundation was notified a week earlier that the "benefactor" ODF Community group Louis Gutierrez had asked IBM and Oracle to put together in Massachusetts had failed.  This was the group Louis formed around the da Vinci plugin and our InfoSet APi. 

    Florian has been hired by Novell, and his first day on the job he finds out about the IBM - Novell deal with Microsoft.  Now he has write the MOOXML plugin for OpenOffice using the MS-CleverAge Translator Project work.  So he writes this message to the ODF TC [office] list. 

    The interoperability enhancements Florian suggests are based on the <interoperability eXtensions> submitted in August to the ODF Metadata SC for consideration.

    The first element in this list tha tFlorian chose to tackle related to "Lists".  He called it the "LIst Override Proposal".  This became the now infamous "List Enhancement Proposal War" that resulted in Sun having OASIS boot out the Foundation.

    Such is life in big vendor ODF'dom

    ~ge~

1 - 20 of 47 Next › Last »
Showing 20▼ items per page