Skip to main content

Home/ Document Wars/ Group items tagged standards

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Graham Perrin

Next round of ODF vs OOXML… « CyberTech Rambler - 0 views

ctrambler.wordpress.com/...next-round-of-odf-vs-ooxml

shared by Graham Perrin on 12 May 09 - Cached
  • approval of an standard that wasn’t ready
  • no one at ISO listened
  • The whole OOXML thing is a collection of mistakes
  • ...10 more annotations...
  • in the time frame taken to approve it
  • by National Body to trust that BRM has influence
  • by BRM for not attending to every concerns of national bodies
  • for not incorporating BRM resolutions in the published standard
  • OOXML is fundamentally intended to document a format for a pre-existing technology and feature set of recent proprietary systems.
  • years for IS29500 to have a really good debugged version
  • years for ODF to have a good, complete debugged version
  • the nature of big standards
  • sad about OOXML meeting
  • Apple, Oracle and British Library did not even bothered to turn up
  • Paul Merrell on 13 May 09
     
    Found myself blocked from commenting on that blog entry for some reason. Here's the comment I tried to post. @ctrambler "Between vendor-heavy or user-heavy, I choose vendor-heavy. It is after all, a office document format designed for office application. Linking with other systems is important, but it is not the ultimate aim." That statement bespeaks lack of familiarity with what an IT standard *IS.* But it is a lack of familiarity shared by all too many who work on IT standards. Standards are about uniformity, not variability. An international standard must by law specify [i] all characteristics [ii] of an identifiable product or group of products [iii] only in mandatory "must" or "must not" terms. WTDS 135 EC - Asbestos, (World Trade Organization Appellate Body; 12 March 2001; HTML version), para. 66-70, http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm And IT standards in particular must "clearly and unambiguously specify all conformity requirements that are essential to achieve the interoperability." ISO/IEC JTC 1 Directives, (5th Ed., v. 3.0, 5 April 2007) pg. 145, http://www.jtc1sc34.org/repository/0856rev.pdf Absent such specifications, a standard is a standard in name only. A standard is intended to establish a market in standardized goods, creating economic efficiency and competition. This is perhaps most simply illustrated with weights and measures, where a pound of flour must weigh the same regardless which vendor sells the product. But we can also see it in the interoperability context, e.g., with standardized nuts, bolts, and wrenches. Absent sufficient specificity to enable and require interoperability, ODF and OOXML create technical barriers to trade rather than promoting competition. And the Agreement on Technical Barriers to Trade unambiguously requires that national standardization bodies "shall ensure that technical regulations [includes international standards] are not prepared, adopted or applied with a v
  • Paul Merrell on 13 May 09
     
    (continuation). . And the Agreement on Technical Barriers to Trade unambiguously requires that national standardization bodies "shall ensure that technical regulations [includes international standards] are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade." http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm#articleII So while I agree that linking IT systems may not invariably be the ultimate goal, sufficient specificity in an IT standard to do so is in fact a threshold user and legal requirement. Otherwise, one has vendor lock-in and definition of the standard is controlled by the vendor with the largest market share, not the standard itself. Neither ODF nor OOXML met than threshold for eligibility as international standards and still do not. In both cases, national standardization bodies voted to adopt the standards without paying heed to fundamental legal and user requirements.
Gary Edwards

ODF - the state of play - The future of ODF under OASIS, now that the... - 1 views

www.it-director.com/...-that-the-standards-war-is-won

ODF msooxml

shared by Gary Edwards on 20 Nov 15 - No Cached
  • Gary Edwards on 20 Nov 15
     
    "ODF - open document format - is an open, XML-based rich document format that has been adopted as the standard for exchanging information in documents (spreadsheets, charts, presentations and word processing documents), by many governments and other organisations (see, for example, here), including the UK Government. This is despite strong opposition by Microsoft; but I have seen Microsoft's proposed "open XML" standard and, frankly, it is huge and horrid (in the word of standards, these go together). If I remember correctly, the early draft I saw even incorporated recognition of early Excel leap-year bugs into the standard. ODF is now a pukka ISO standard, maintained by OASIS, under the proud banner: "The future is interoperability". My personal thoughts, below, are prompted by an ODF session at ApacheCon Core titled "Beyond OpenOffice: The State of the ODF Ecosystem" held by Louis Suárez-Potts (community strategist for Age of Peers, his own consultancy, and the Community Manager for OpenOffice.org, from 2000 to 2011), and attended by very few delegates - perhaps a sign of current level of interest in ODF within the Apache community. Nevertheless, and I am talking about the ODF standard here, not Apache Open Office (which is currently my office software of choice) or its Libre Office fork (which seems to be where the excitement, such as it is, is, for now), the standards battle, or one battle, has been won; we have a useful Open Document Format, standardised by a recognised and mature standards organisation, and even Microsoft Office supports it. That's good. So what could be the problem? Well, I don't care whether I use ODF from Open Office, Libre Office or even Office 365, I just want to be sure that everyone else can read my ODF documents (with a .odt, .ods or .odp extension, for text, presentation or spreadsheet, respectively), with whatever software they like; and that they'll either see exactly the functionality and formatting I see; or a well defined (an
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.  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.  Double the number of applications to 8 total, and there will be 56 types of interoperability between them:
  • In the standards-based scenario, the standard itself is the central mechanism for enabling interoperability between implementations: This diagram is much simpler
  • 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.  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
  • 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.
  • 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
  • All complex software has bugs, and some bugs can present significant challenges to interoperability.  Let’s consider the case that 3 of the 4 applications have bugs that affect interoperability, as shown in the diagram to the right.
  • 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
  • different interpretations
  • (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.  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

Is It Game Over? - ODF Advocate Andy UpDegrove is Worried. Very Worried - 0 views

www.consortiuminfo.org/...article.php

iso oasis odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • This 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.
  • Gary Edwards on 12 Dec 07
     
    Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard.  MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007.  Just a bit over 60 days from today.

    Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:

    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, wh
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

EICTA White Paper on Standardisation and Interoperability - 0 views

74.125.155.132/search

interoperability

shared by Gary Edwards on 03 Aug 09 - Cached
  • Gary Edwards on 03 Aug 09
     
    Standardisation is one of the key facilitators for interoperability of networks, services and equipment. Interoperability in this sense has gained increasing attention and demand inthe market-place. Thus, in response to market-driven needs interoperability is becomingan important requirement in standards projects.This white paper examines the standards development process as well as the actors involved and proposes a set of recommendations in standards development that will help to address interoperability challenges that may occur and can be observed instandardisation. At the same time it provides an agreed industry position on key aspects for standards development. Observing these recommendations - as is done by a lot of actors in standardisation already, including formally established standards setting bodies - may help to increase the level of interoperability in standardisation. This white paper aims at strengthening the awareness to observe interoperability issues at an early stage and make those issues an important consideration as part of the standards-setting process. EICTA's recommendations for the standards development process:
Gary Edwards

ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for... - 0 views

www.infotechfrance.com/...affichage_signets.pl

cdf interoperability iso odf officeopenxml ooxml opendocment standards

shared by Gary Edwards on 12 Dec 07 - Cached
  • AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
  • Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.   Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      Here's the meat of the French convergence proposal.
  • Gary Edwards on 12 Dec 07
     
    French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?

    The plan has four parts:

    "Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."

    "Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."

    "Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."

    Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."




    So there you go.  A solution that removes ODF and OOXML from the clam
Gary Edwards

Standardization by Corporation | Can big application vendors be stopped from corrupting... - 0 views

talkback.zdnet.com/;jsessionid=lpZyhV8gwAfQR3UXAr

bryan cdf ecma ibm iso mary-jo microsoft oasis odf ooxml opendocument sun w3c zdnet

shared by Gary Edwards on 12 Dec 07 - Cached
  • Standardization by Corporation Maybe i spoke to soon. This just came in from ISO, the resignation letter of the SC34WG1 Chairman who has completed his three year term. There is a fascinating statement at the end of the Martin Bryan letter. "The disparity of rules for PAS, Fast-Track and ISO committee generated standards is fast making ISO a laughing stock in IT circles. The days of open standards development are fast disappearing. Instead we are getting “standardization by corporation”, something I have been fighting against for the 20 years I have served on ISO committees. I am glad to be retiring before the situation becomes impossible..." When corporations join open standards or open source efforts, they arrive with substantial but most welcome financial and expert resources. They also bring marketshare and presence. And, they bring business objectives. They have a plan. As long as the corporate plan is aligned with the open standards - open source community work, all is fine. In fact it's great. For sure though there will come a time when the corporate plan asserts it's direction, and there is possible conflict. At this point, the very same wealth of resources that were cause for celebration can become cause for disappointment and disaster. One of the more troubling things i've noticed is that corporations treat everything as a corporate asset to be traded, bartered and dealt for shareholder advantage and value. This includes patents and interoperability issues which not surprisingly are wrapped into open standards and open source efforts. Rather than embrace the humanitarian – community of shared interest drivers of open standards and open source, corporations naturally plot to get maximum value out of the resources they commit. A primary example of this is Sun's use of OpenOffice, ODF, and an anti trust settlement disaster that left them at the mercy of Microsoft.
  • Gary Edwards on 12 Dec 07
     
    Will ISO follow either the AFNOR or Brittish proposals to merge ODF and OOXML? I think so. If they continue on their current path of big vendor sponsored document wars, ISO will beocme irrelevant. Sooner or later the ISO National Bodies must take back the standards process from corporate corruption and influence. One thing is clear. Neither Microsoft or IBM is about to compromise. IBM has had many chances to improve ODF's interoperability with Microsoft Office and the Office documents, but has been steadfast in their stubborn refusal to concede an inch. Microsoft hides behind their legacy installed base of over 550 million MSOffice desktops. There simply isn't a pragmatic or cost effective way of transitioning the installed base to ODF without either seriously re writing and replacing those applications, or, changing ODF to be compatible. The marketplace is clear on what they intend on doing. Pragmatism will rule. Productivity trumps standards initiatives whenever they are out of sink. In the face of this clear marketplace intent, one would think IBM might compromise on ODF. No way! They are intent on using ODF to force a market wide rip out and replace of MSOffice. Most people assume that there are two opposing groups at war here; the Microsoft OOXML group vs. the IBM ODF group. This isn't an accurate view at all. There is a third, middle group of developers working the treacherous space of conversion - the no man'sland between OOXML MSOffice and ODF OpenOffice. The conversion group know the problems involved, and are actually trying to dliver marketplace facing solutions. The vendors of course are in this war to the bitter end, and could care less about the damage they cause to end users. It's also true that the conversion group seeks to bridge desktop productivity into the larger, highly interoeprable web platform. It's also possible that ISO will chose to merge
Gary Edwards

Microsoft's Quest for Interoperability and Open Standards - 0 views

www.cmswire.com/...-and-open-standards-004220.php

webkit interop open-web open-standards microsoft

shared by Gary Edwards on 17 Apr 09 - Cached
  • Gary Edwards on 17 Apr 09
     
    Interesting article discussing the many ways Microsoft is using to improve the public perception that they are serious about interoperability and open formats, protocols and interfaces. Rocketman attended the recent ISO SC34 meeting in Prague and agrees that Microsoft has indeed put on a new public face filled with cooperation, compliance and unheard of sincerity.

    He also says, "Don't be fooled!!!"

    There is a big difference between participation in vendor consortia and government sponsored public standards efforts, and, actual implementation at the product level. Looking at how Microsoft products implement open standards, my take is that they have decided on a policy of end user choice. Their applications offer on the one hand the choice of aging, near irrelevant and often crippled open standards. And on the other, the option of very rich and feature filled but proprietary formats, protocols and interfaces that integrate across the entire Microsoft platform of desktop, devices and servers. For instance; IE8 supports 1998 HTML-CSS, but not the advanced ACiD-3 "HTML+" used by WebKit, Firefox, Opera and near every device or smartphone operating at the edge of the Web. (HTML+ = HTML5, CSS4, SVG/Canvas, JS, JS Libs).

    But they do offer advanced .NET-WPF proprietary alternative to Open Web HTML+. These include XAML, Silverlight, XPS, LINQ, Smart Tags, and OOXML. Very nice.

    "When an open source advocate, open standards advocate, or, well, pretty much anyone that competes with Microsoft (news, site) sees an extended hand from the software giant toward better interoperability, they tend to look and see if the other hand's holding a spiked club.

    Even so, the Redmond, WA company continues to push the message that it has seen the light regarding open standards and interoperability...."

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.  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.  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

Slamming the door shut on MS OOXML - 0 views

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

cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact. No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one? Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.
  • Gary Edwards on 12 Dec 07
     
    Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

    ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.

    Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

    Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.

    This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.

    In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.

    It's a devastating argument.

Gary Edwards

Brendan's Roadmap Updates: My @media Ajax Keynote - 0 views

weblogs.mozillazine.org/...my_media_ajax_keynote.html

shared by Gary Edwards on 11 Jan 08 - Cached
  • Standards often are made by insiders, established players, vendors with something to sell and so something to lose. Web standards bodies organized as pay-to-play consortia thus leave out developers and users, although vendors of course claim to represent everyone fully and fairly. I've worked within such bodies and continue to try to make progress in them, but I've come to the conclusion that open standards need radically open standardization processes. They don't need too many cooks, of course; they need some great chefs who work well together as a small group. Beyond this, open standards need transparency. Transparency helps developers and other categories of "users" see what is going on, give corrective feedback early and often, and if necessary try errant vendors in the court of public opinion.
    • Gary Edwards
      Gary Edwards on 11 Jan 08
       
      Brendan's comment about the open standards process and the control big vendors have over that process is exactly right. The standards contsortia are pay to play orgs controlled entirely by big vendors. OASIS and the OpenDocuemnt Technical Committee are not exceptions to this problematic and troublesome truth.
      The First Law of the Internet is that Interoperability trumps everything - including innovation. The problem with vendor driven open standards is that innovation ontinually trumps interoperability. So much so that interop is pretty much an after thought - as is the case with ODF and OOXML!
      The future of the Open Web will depend on open source communities banding together with governemnts and user groups to insist on the First Law of the Internet: Interoeprability. If they don't, vendors will succeed in creating slow moving web standards designed to service their product lines. Vendor product lines compete and are differentiated by innovative features. Interoeprability on the other hand is driven by sameness - the sharing of critical features. Driving innovation down into the interop layer is what the open standards process should be about. But as long as big vendors control that process, those innovations will reside at the higher level of product differentiation. A level tha tcontinues to break interoperability!
Gary Edwards

War rages on over Microsoft's OOXML plans: Insight - Software - ZDNet Australia - 0 views

www.zdnet.com.au/...0,139023769,339284737,00.htm

australia cdf interop iso microsoft odf ooxml opendocument

shared by Gary Edwards on 27 Dec 07 - Cached
  • "We feel that the best standards are open standards," technology industry commentator Colin Jackson, a member of the Technical Advisory committee convened by StandardsNZ to consider OOXML, said at the event. "In that respect Microsoft is to be applauded, as previously this was a secret binary format." Microsoft's opponents suggest, among a host of other concerns, that making Open XML an ISO standard would lock the world's document future to Microsoft. They argue that a standard should only be necessary when there is a "market requirement" for it. IBM spokesperson Paul Robinson thus describes OOXML as a "redundant replacement for other standards". Quoting from the ISO guide, Robinson said that a standard "is a document by a recognised body established by consensus which is aimed at achieving an optimum degree of order and aimed at the promotion of optimum community benefits". It can be argued that rather than provide community benefit, supporting multiple standards actually comes at an economic cost to the user community. "We do not believe OOXML meets these objectives of an international standard," Robinson said.
  • Gary Edwards on 27 Dec 07
     
    "aimed at achieving an optimum degree of order .... and .... aimed at the promotion of optimum community benefits:. Uh, excuse me Mr. Robinson, tha tsecond part of your statement, the one concerning optimum community benefits - that would also disqualify ODF!! ODF was not designed to be compatible with the 550 million MSOffice desktops and their billions of binary docuemnts. Menaing, these 550 million users will suffer considerable loss of information if they try to convert their existing documents to ODF. It is also next to impossible for MSOffice applications to implement ODF as a fiel format due to this incompatbility. ODF was designed for OpenOffice, and directly reflects the way OpenOffice implements specific document structures. The problem areas involve large differences between how OpenOffice implments these structures and how MSOffice implements these same structures. The structures in question are lists, fields, tables, sections and page dynamics. It seems to me that "optimum community benefits" would include the conversion and exchange of docuemnts with some 550 million users!!!! And ODF was clearly not designed for that purpose!
  • Gary Edwards on 27 Dec 07
     
    I don't agree with this statement from Microsoft's Oliver Bell. As someone who served on the OASIS ODF Technical Committee from it's inception in November of 2002 through the next five years, i have to disagree. It's not that Microsoft wasn't welcome. They were. It's that the "welcome" came with some serious strings. Fo rMicrosoft to join OASIS would have meant strolling into the camp of their most erstwhile and determined competitors, and having to ammend an existing standard to accomodate the implementation needs of MSOffice. There is simply no way for the layout differences between OpenOffice and MSOffice to be negotiated short of putting both methodologies into the spec. Meaning, the spec would provide two ways of implementing lists, tables, fields, sections and page dynamics. A true welcome would have been for ODF to have been written to accomodate these diferences. Rather than writing ODF to meet the implementation model used by OepnOffice, it would have been infinitely better to wrtite ODF as a totally application independent file format using generic docuemnt structures tha tcould be adapted by any application. It turns out that this is exactly the way the W3C goes about the business of writing their fiel format specifications (HTML, XHTML, CSS, XFORMS, and CDF). The results are highly interoperable formats that any applciation can implement.
  • Gary Edwards on 27 Dec 07
     
    You can harmonize an application specific format with a generic, applicaiton independent format. But you can't harmonize two application specific formats!!!!
    The easy way to solve the document exchange problem is to leave the legacy applications alone, and work on the conversion of OOXML and ODF docuemnts to a single, application independent generic format. The best candidate for this role is that of the W3C's CDF.
    CDF is a desription of how to combine existing W3C format standards into a single container. It is meant to succeed HTML on the Web, but has been designed as a universal file format.
    The most exciting combination is that of XHTML 2.0 and CSS in that it is capable of handling the complete range of desktop productivity office suite documents. Even though it's slightly outside the W3C reach, the most popular CDF compound is that of XHTML, CSS and JavaScript. A combination otherwise known as "AJAX".
Gary Edwards

ODF and OOXML - The Final Act - 0 views

www.idm.net.au/story.asp

din fraunhofer harmonization iso odf ooxml opendocument openxml

shared by Gary Edwards on 04 Feb 08 - Cached
  • The format war between Microsoft’s Open Office XML (OOXML) and the open source OpenDocument Format (ODF) has flared up again, right before the looming second OOXML ISO vote in March.
  • “ISO has a policy that, wherever possible, there should only be one standard to maximise interoperability and functionality. We have an international standard for digital documentation, ODF,” IBM’s local government programs executive Kaaren Koomen told AustralianIT.
  • ODF has garnered some criticism for being a touch limited in scope, however, one of its strengths is that it has already been accepted as a worldwide ISO standard. Microsoft’s format on the other hand, has been criticised for being partially proprietary, and even a sly attempt by the software giant to hedge its bets and get in on open standards while keeping as many customers locked into its solutions as possible.
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      A "touch limited in scope"? Youv'e got to be kidding. ODF was not defined to be compatible with the billions of MSOffice binary (BIN) documents. Nor was it designed to further interoperability with MSOffice.
      Given that there are over 550 million MSOffice desktops, representing upwards of 95% of all desktop productivity environments, this discrepancy of design would seem to be a bit more than a touch limited in scope!
      Many would claim that this limitation was due to to factors: first that Microsoft refused to join the OASIS ODF TC, which would have resulted in an expanded ODF designed to meet the interoperability needs of the great herd of 550 million users; and second, that Microsoft refused to release the secret binary blueprints.
      Since it turns out that both IBM and Sun have had access to the secret binary blueprints since early 2006, and in the two years since have done nothing to imptove ODF interop and conversion fidelity, this second claim doesn't seem to hold much water.
      The first claim that Microsoft didn't participate in the OASIS ODF process is a bit more interesting. If you go back to the first OASIS ODF Technical Committee meeting, December 16th, 2002, you'll find that there was a proposal to ammend the proposed charter to include the statemnt that ODF (then known as Open Office XML) be compatible with existing file formats, including those of MSOffice. The "MSOffice" reference was of course not included because ODF sought to be application, platform and vendor independent. But make no mistake, the discussion that day in 2002 was about compatibility and the conversion of the legacy BIN's into ODF.
      The proposal to ammend the charter was tabled. Sun objected, claiming that people would interpret the statement as a direct reference to the BIN's, clouding the charter's purpose of application, platform and vendor independence. They proposed that the charter ammendment b
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      Will harmonization work? I don't think so. The problem is that the DIN group is trying to harmonize two application specific formats. OpenOffice has one way of implementing basic document structures, and MSOffice another. These differences are directly reflected in the related formats, ODF and OOXML. Any attempts to harmonize ODF and OOXML will require that the applications, OpenOffice and MSOffice, be harmonized! There is no other way of doing this unless the harmonized spec has two different methods for implementing basic structures like lists, tables, fields, sections and page dynamics. Not to mention the problems of feature disparities. If the harmonized spec has two different implementation models for basic structures, interoeprability will suffer enormously. And interoperability is after all the prupose of the standardization effort. That brings us to a difficult compromise. Should OpenOffice compromise it's "innovative" features and methods in favor of greater interoperability with MSOffice and billions of binary documents? Let me see, 100 million OpenOffice installs vs. 550 MSOffice installs bound to workgroup-workflow business processes - many of which are critical to day to day business operations? Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice innovation! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset. Events in Massachusetts prove otherwise! On July 2nd, 2007, Sun delivered to Massachusetts the final version of their ODF plug-in for MSOffice. That night, after reviewing and testing the 135 critical documents, Massachusetts made a major change to their ETRM web site. They ammended the ETRM to fully recognize OOXML as an acceptable format standard going forward. The Massachusetts decision to overturn th
  • ...1 more annotation...
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      The Burton Group did not recommend that ISO recognize OOXML as a standard! They pointed out that the marketplace is going to implement OOXML by default simply because it's impossible to implement ODF in situations where MSOffice dominates. ISO should not go down the slippery slope of recognizing application-platform-vendor specific standards. They already made that mistake with ODF, and recognizing OOXML is hardly the fix. What ISO should be doign is demanding that ODF fully conform with ISO Interoeprability Requirements, as identified in the May 2006 directive! Forget OOXML. Clean up ODF first.
  • Gary Edwards on 04 Feb 08
     
    Correcto mundo! There should be only one standard to maximise interoeprability and functionality. But ODF is application specific to the way OpenOffice works. It was not designed from a clean slate. Nor was the original 2002 OpenOffice XML spec designed as an open source effort! Check the OOo source code if you doubt this claim. The ONLY contributors to Open Office XML were Sun employees! What the world needs is in fact a format standard designed to maximise interoperability and functionality. This requires a total application-platofrm-vendor independence that neither ODF or OOXML can claim. The only format that meets these requirements is the W3C's family of HTML-XML formats. These include advancing Compound Docuemnt Framework format components such as (X)HTML-5, CSS-3, XForms, SVG and SMiL.. The W3C's CDF does in fact meet the markeplace needs of a universal format that is open, unencumbered and totally application, platform and vendor independent. The only trick left for CDF is proving that legacy desktop applications can actually implement conversions from existing in-memory-binary-representations to CDF without loss of information.
Gary Edwards

XML.com: Standard Data Vocabularies Unquestionably Harmful - 0 views

www.xml.com/...perry.html

odf ooxml presentation semantics xml

shared by Gary Edwards on 21 Jan 08 - Cached
  • At the onset of XML four long years ago, I commenced a jeremiad against Standard Data Vocabularies (SDVs), to little effect. Almost immediately after the light bulb moment -- you mean, I can get all the cool benefits of web in HTML and create my own tags? I can call the price of my crullers <PricePerCruller>, right beside beside <PricePerDonutHole> in my menu? -- new users realized the problem: a browser knows how to display a heading marked as <h1> bigger and more prominently than a lowlier <h3>. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for <Cruller> and, especially, not as distinct from <DonutHole> has been readily understood to demonstrate the separation of data structure expressed in XML from its display, which requires the application of styling to accomodate the fixed expectations of the browser. What has not been so readily accepted is that there should not be a standard expectation for how a data element, as identified by its markup, should be processed by programs doing something other than simple display.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      ODF and OOXML are contending to become the Standard Data Vocabulary for desktop office suite XML markup. Sun and Microsoft are proposing the standardization of OpenOffice and MSOffice custom defined XML tags for which there are no standard display expectations. The display expectations must therefore be very carefully described: i.e. the semantics of display fully provided.
      In this article Walter Perry is pointing out the dangers of SDV's being standardized for specific purposes without also having well thought out and fully specified display semantics. In ODF - OOXML speak, we would call display presentation, or layout, or "styles".
      The separation of content and presentation layer of each is woefully underspecified!
      Given that the presnetation layers of both ODF and OOXML is directly related to how OpenOffice and MSOffice layout engines work, the semantics of display become even more important. For MSOffice to implement an "interoperable" version of OpenOffice ODF, MSOffice must be able to mimic the OpenOffice layout engine methods. Methods which are of course quite differeent from the internal layout model of MSOffice. This differential results in a break down of conversion fidelity, And therein lies the core of the ODF interoeprability dilemma!
  • There have also emerged a few "horizontal" data vocabularies, intended for expressing business communication in more general terms. One of these is the eXtensible Business Reporting Language (XBRL), about which more below. Most recently, governments and governmental organizations have begun to suggest and eventually mandate particular SDVs for required filings, a development which expands what troubles me about these vocabularies by an order of magnitude.
  • ...5 more annotations...
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Exactly! When governments mandate a specific SDV, they also are mandating inherent concepts and methods unique to the provider of the SDV. In the case of ODF and OOXML, where the presentation layers are application specific and woefully underspecified, interoperability becomes an insurmountable challenge. Interop remains stubbornly application bound.
      Furthermore, there is no way to "harmonize" or "map" from one format to another without somehow resolving the application specific presentation differences.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      "in the nature of the SDV's themselves is the problem of misstatement, of misdirection of naive interpretation, and potential for fraud.
      Semantics matter! The presentation apsects of a document are just as important as the content.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Walter: "I have argued for years that, on the basis of their mechanism for elaborating semantics, SDVs are inherently unreliable for the transmission or repository of information. They become geometrically less reliable when the types or roles of either the sources or consumers of that information increase, ending at a nightmarish worst case of a third-order diminution of the reliability of information. And what is the means by which SDVs convey meaning? By simple assertion against the expected semantic interpretations hard-coded into a process consuming the data in question.
      At this point in the article i'm hopign Walter has a solution. How do we demand, insist and then verify that SDV's have fully specifed the semantics, and not jus tpassed along the syntax?
      With ODF and OOXML, this is the core of the interoperability problem. Yet, there really is no way to separate the presentation layers from the uniquely different OpenOffice and MSOffice layout engine models.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Interesting concept here: "the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it ........ it is these expert connections which SDV's are intended to sever.
      Not quite sure what to make of that statement? When an SDV is standardized by ISO, the expectation is that the connections between data and processes would be fully understood, and implementations consistent across the board.
      Sadly, ODF is ISO approved, but doesn't come close to meeting these expectations. ODF interop might as well be ZERO. And the only way to fix it is to go into the presentation layer of ODF, strip out all the application specific bindings, and fully specifiy the ssemantics of layout.
  • In short, the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it. It is precisely these expert connections which standard data vocabularies are intended to sever.
Gary Edwards

Barr: What's up at the OpenDocument Foundation? - Linux.com - 0 views

www.linux.com/121034

cdf odf ooxml w3c

shared by Gary Edwards on 12 Dec 07 - Cached
  • The OpenDocument Foundation, founded five years ago by Gary Edwards, Sam Hiser, and Paul "Buck" Martin (marbux) with the express purpose of representing the OpenDocument format in the "open standards process," has reversed course. It now supports the W3C's Compound Document Format instead of its namesake ODF. Yet why this change of course has occurred is something of a mystery.
  • Gary Edwards on 12 Dec 07
     
    More bad information, accusations and smearing innuendo.  Wrong on the facts,  Emotionally spent on the conclussions.  But wow it's fun to see them with their panties in such a twist.

    The truth is that ODF is a far more "OPEN" standard than MS-OOXML could ever hope to be.  Sam's Open Standards arguments for the past five years remain as relevant today as when he first started makign them so many years ago.

    The thing is, the Open Standards requirements are quite different than the real world Implementation Requirements we tried to meet with ODF.

    The implementation requirements must deal with the reality of a world dominated by MSOffice.  The Open Standards arguments relate to a world as we wish it to be, but is not.

    It's been said by analyst advising real world CIO's that, "ODF is a fine open standards format for an alternative universe where MSOffice doesn't exist".

    If you live in that alternative universe, then ODF is the way to go.  Just download OpenOffice 2.3, and away you go.  Implementation is that easy.

    If however you live in this universe, and must deal with the impossibly difficult problem of converting existing MSOffice documents, applications and processes to ODF, then you're screwed. 

    All the grand Open Standards arguments Sam has made over the years will not change the facts of real world implmentation difficulities.

    The truth is that ODF was not designed to meet the real world implmentation requirements of compatibility with existing Microsoft documents (formats) and, interoperability with existing Microsoft Office applications.

    And then there are the problmes of ODF Interoperability with ODF applications.  At the base of this problem is the fact that compliance in ODF is optional.  ODF applications are allowed to routinely destroy metadata information needed (and placed into the markup) by other applications.<b
Gary Edwards

The Meaning of Open Standards - 0 views

www.csrstds.com/openstds.html

ecma iso oasis odf ooxml w3c

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    The marbux comment:

    See particularly section 6.8 and its discussion of "etiquettes," which sounds like CDF profiles to me.

    This 1998 academic paper on open standards could give us a solid foundation to build our arguments for Universal Interop from. I may have forwarded this link before, roughly a year ago. Here is the abstract of the paper:

    This paper develops the argument that many Information Technology standardization processes are in transition from being controlled by standards creators to being controlled by standards implementers. The users of standardized implementations also have rights that they wish addressed. Ten basic rights of standards creators, implementers and users are identified and quantified. Each of these ten rights represents an aspect of Open Standards. Only when all ten rights are supported will standards be open to all.

    It builds upon a previous work by Bruce Perens. Well worth the read.

Gary Edwards

God Save the Queen! - 0 views

openstack.blogspot.com

ansi/incits ecma ecma376 eoxml imported:del.icio.us iso/iec microsoft oasis odf ooxml opendocument openstandards

shared by Gary Edwards on 12 Dec 07 - Cached
  • Redmond Yankees in the World Court of King Arthur ANSI/INCiTS has completed their review of Ecma 376, and is ready to cast their ISO/IEC Contradiction Review Phase Fast Track Ballot in favor of Ecma 376 being rammed through ISO. As Sam Hiser points out in his PlexNex blog, not only are the findings of contradictions, inconsistencies, and proprietary dependencies pouring into the public view, there's not much an American can do about it. ANSI/INCiTS has determined that no contradictions exist."
  • Gary Edwards on 12 Dec 07
     
    Looks like the road to open standards now detours through Redmond, Washington.  Can we still call the destiny "open standards" if proposals have to be filtered through the Microsoft business plan for world domination?  This is not a good day for America.
  • ...1 more comment...
  • Gary Edwards on 12 Dec 07
     
    The British Standards Institute, which represents the UK with the International Standards Organization, has issued a " contradiction" to Microsoft's specification.
  • Gary Edwards on 12 Dec 07
     
    The British Standards Institute, which represents the UK with the International Standards Organization, has issued a " contradiction" to Microsoft's specification.
  • Gary Edwards on 12 Dec 07
     
    The British Standards Institute, which represents the UK with the International Standards Organization, has issued a " contradiction" to Microsoft's specification.
Gary Edwards

Comments Received in Response to JTC 1 N 8455 - 30 Day Review for Fast Track Ballot ECM... - 0 views

www.incits.org/...DIS29500.htm

ecma376 iso/iec iso26300 odf ooxml

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    Well, this is interesting.

    What part of "Executive Board" makes you think they read 6,000 page XML specifications? <ge>

    I think, in the best bureaucratic tradition, they argued definitions until they convinced themselves that they didn't need to do anything.  They decided that one standard contradicts another standard only if the proposed standard causes the existing standard not to work.  This is from analogy with the Chinese WAPI WiFi networking standard last year that was defeated because the protocol caused radio interference with existing 801.11 networks.  So they said that OOXML did not contradict ODF because both files could exist on the same disk without interfering with each other.   You will note that thiss argument can be used for every XML format, every programming language, every operating system, in fact every software standard, since software is ultimately data, and data can be segregated on disks.  So they essentially chose a definition so narrow that it nullified the concept of "contradiction" for most of what JTC1 has authority over.<!-- D(["mb","<div><br><span style\u003d\"color:rgb(0, 0, 153)\"><ge>  Wait a second.   You cannot have a OOXML document and a ODF document sitting on the same disk without having them interfer with each other.  We just proved that with our tests of both ACME 374 and ODF Da Vinci plugin on the latest release of MSOffice Word 2007.\n</span><br style\u003d\"color:rgb(0, 0, 153)\"><br style\u003d\"color:rgb(0, 0, 153)\"><span style\u003d\"color:rgb(0, 0, 153)\">OOXML clearly does interfere with the loading of an ODF file into MSWord 2007.  In prior versions of MSWord (98, 2000, XP, 2003
Alex Brown

Doug Mahugh : Tracked Changes - 0 views

blogs.msdn.com/...tracked-changes.aspx

shared by Alex Brown on 14 May 09 - Cached
  • Much was made during the IS29500 standards process of the difference in the size of the ODF and Open XML specifications.&nbsp; This is a good example of where that difference comes from: in this case, a concept glossed over in three vague sentences of the ODF spec gets 17 pages of documentation in the Open XML spec.
    • Alex Brown
      Alex Brown on 14 May 09
       
      This is the nub; OOXML may be overweight, but ODF is severely undernourished as a spec.
  • Paul Merrell on 14 May 09
     
    Alex, I know from your previous writings that you do not regard OOXML as completely specified. But your post might be so misinterpreted. In my view, neither ODF nor OOXML has yet reached the threshold of eligibility as an international standard, completely specifying "clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." ISO/IEC JTC 1 Directives, Annex I. . OOXML is ahead of ODF in some aspects of specificity, but the eligibility finish line remains beyond the horizon for both.
  • ...2 more comments...
  • Alex Brown on 14 May 09
     
    Paul, that's right - though so far the faulty things in OOXML turn out to be more round the edges as opposed to ODF's central lapses. Still, it's early days in the examination of OOXML so I'm reserving making any firm call on the comparative merits of the specs until I have read a lot (a lot) more. Is there an area of OOXML you'd say was particularly underbaked? I'm quite interested in the fact that neither of these beasts specify scripting languages ...
  • Paul Merrell on 14 May 09
     
    Hi, Alex, Most seriously, there are no profiles and accompanying requirements to enable less featureful apps to round trip documents with more featureful apps, a la W3C Compound Document by Reference Framework. That's an enormous barrier to market entry and interoperability. That defect reacts synergistically with the dearth of semantic conformity requirements, with the incredible number of options including those 500+ identified extension points, and with a compatibility framework for extensions that while a good start leaves implementers far too much discretion in assigning and processing compatibility attributes. There are also major harmonization issues with other standards that get in the way of transformations, where Microsoft originally rolled its own rather than embracing existing open standards. I think it not insignificant that OOXML as a whole is available only under a RAND-Z pledge rather than being available for the entire world. The patent claims need to be identified and worked around or a different rights scheme needs Microsoft management's promulgation. This is a legal interoperability issue as opposed to technical, but an interoperability barrier nonetheless, an "unnecessary obstacle to international trade" in the sense of the Agreement on Technical Barriers to Trade. And absent a change by Microsoft in its rights regime, the work-arounds are technical. This is not to suggest that ODF lacks problems in regard to the way it implements standards incorporated by reference. The creation of unique OASIS namespaces rather than doing the needed harmonizing work with the relevant W3C WGs is a large ODF tumor in need of removal and reconstructive surgery. I'm not sure what is happening with the W3C consultation in that regard. I worked a good part of the time over several months comparing ODF and Ecma 376, evaluating their comparative suitability as document exchange formats. I gave up when it climbed well past 100 pages in length because the de
  • Paul Merrell on 14 May 09
     
    1. Full-featured editors available that are capable of not generating application-specific extensions to the formats? 2. Interoperability of conforming implementations mandatory? 3. Interoperability between different IT systems either demonstrable or demonstrated? 4. Profiles developed and required for interoperability? 5. Methodology specified for interoperability between less and more featureful applications? 6. Specifies conformity requirements essential to achieve interoperability? 7. Interoperability conformity assessment procedures formally established and validated? 8. Document validation procedures validated? 9. Specifies an interoperability framework? 10. Application-specific extensions classified as non-conformant? 11. Preservation of metadata necessary to achieve interoperability mandatory? 12. XML namespaces for incorporated standards properly implemented? (ODF-only failure because Microsoft didn't incorporate any relevant standards.) 13. Optional feature interop breakpoints eliminated? 14. Scripting language fully specified for embedded scripts? 15. Hooks fully specified for use by embedded scripts? 16. Standard is vendor- and application-neutral? 17. Market requirement -- Capable of converging desktop, server, Web, and mobile device editors and viewers? (OOXML better equipped here, but its patent barrier blocks.)
  • Paul Merrell on 14 May 09
     
    Didn't notice that my post before last was chopped at the end until after I had posted the list. Then Diigo stopped responding for a few minutes. Anyway, the list is short summation of my research on the comparative suitabilities of ODF 1.1 and Ecma 376 as document exchange formats, winnowed to the defects they have in common except as noted. The research was never completed because in the political climate of the time, the world wasn't ready to act on the defects. The criteria applied were as objective as I could make them; they were derived from competition law, JTC 1 Directives, and market requirements. I think the list is as good today in regard to IS 29500 as it was then to Ecma 376, although I have not taken an equally deep dive into 29500. You might find the list useful, albeit there is more than a bit of redundancy in it.
1 - 20 of 199 Next › Last »
Showing 20▼ items per page