Skip to main content

Home/ Document Wars/ Group items matching "help" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

Brian Jones: Open XML Formats : OASIS ODF committee considering joining DIN to help with translation and interop - 0 views

blogs.msdn.com/...h-translation-and-interop.aspx

shared by Gary Edwards on 31 Jan 08 - Cached
  • OASIS ODF committee considering joining DIN to help with translation and interop This is very cool. It looks like the OASIS committee is looking at coming on board to help out with the work going on in DIN to help understand the translation between Open XML and ODF: http://www.oasis-open.org/archives/office/200801/msg0004
Gary Edwards

Hunting down those who dare help Microsoft | Florian Reuter's Weblog - 0 views

florianreuter.blogspot.com/...new-openoffice.html

odf opendocument opendocument-foundation

shared by Gary Edwards on 12 Dec 07 - Cached
  • New OpenOffice.org target.Many of you probaly know the “WONT FIX” target in the OpenOffice.org issue tracker.What about introducing a new target: “HELPS MICROSOFT”.But why do we need this? These days many people --- especially from the file formats camps --- are extremely sensitive of anything related to compatiblity 'cause they believe it HELPs Microsoft.So lets give the ODF warriors an opportinity to clearly communicate with the users. Give them the “HELPS MICROSOFT” target to publicly exposing the issuer of the bug and the people working on it.
  • Gary Edwards on 12 Dec 07
     
    Another good one from that all around funny guy and document processing expert extraordinaire, Florian Reuter.  This one is way too funny.  I hope the lord of the garage gestapo doesn't take him up on this.
Gary Edwards

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

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

alphadog cdf foundation hiser odf ooxml updegrove

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

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

Free Online PDF to HTML5 Converter, convert pdf to html5 flip book | pubhtml5 - 1 views

pubhtml5.wordpress.com/...convert-pdf-to-html5-flip-book

PDF-HTML5-Converter

shared by Gary Edwards on 05 Aug 14 - No Cached
  • Gary Edwards on 05 Aug 14
     
    "PUB HTML5 automatically converts your legacy content to rich and interactive eBooks. Add interactivity, audios, videos, documents, HTML activities, assessments and more to provide a rich reading experience to your readers. PUB HTML5 enables you to convert your content only once and publish them to multiple platforms like iPad, Android and Windows 8 tablets, PC/Mac and industry standard formats like HTML5 and MOBI. For PUB HTML5, the operating steps of creating fabulous digital magazines are foolproof ones. We extol minimum efforts and maximum outputting effects. Just follow the right procedures of the software, and you can totally customize your own digital magazine on your IPAD. After you have converted your PDF files, with multiple Custom Setting buttons, you get the privilege to design your own digital magazines .You may chose the template you prefer; change the background image; insert rich media including audios, video, images; add links, etc. The whole process can be easily achieved within minutes. Converting your PDFs into HTML5 in order to create iPad magazines can be a simple and worthwhile experience following the right procedures. This video provides you with a step by step procedure on how to create iPad magazines from the very beginning. Even though the PDF is great for posting reading documents like manuals on a website, it can sometimes annoy and even deter your viewers. Public or shared computers may not have a PDF viewer installed or downloading a PDF might not agree with a user's browsing habits. In order to make material in a PDF more accessible to others, converting your PDF to HTML5 file may be an alternative to consider. You can convert PDF to HTML5 free by using the Export tool in PUB HTML5. This option lets you perform different types of on-the-fly PDF conversions. After you have personalized your digital creation by using PUB HTML5 on your PC, you may easily preview your digital work on your IPAD or any other electronic devices. You ma
Gary Edwards

Readium at the London Book Fair 2014: Open Source for an Open Publishing Ecosystem: Readium.org Turns One - 0 views

www.publishersweekly.com/...tem-readium-org-turns-one.html

Readium ePUB OpenWeb-Productivity-Platform HTML5

shared by Gary Edwards on 05 Apr 14 - No Cached
  • Gary Edwards on 05 Apr 14
     
    excerpt/intro: Last month marked the one-year anniversary of the formation of the Readium Foundation (Readium.org), an independent nonprofit launched in March 2013 with the objective of developing commercial-grade open source publishing technology software. The overall goal of Readium.org is to accelerate adoption of ePub 3, HTML5, and the Open Web Platform by the digital publishing industry to help realize the full potential of open-standards-based interoperability. More specifically, the aim is to raise the bar for ePub 3 support across the industry so that ePub maintains its position as the standard distribution format for e-books and expands its reach to include other types of digital publications. In its first year, the Readium consortium added 15 organizations to its membership, including Adobe, Google, IBM, Ingram, KERIS (S. Korea Education Ministry), and the New York Public Library. The membership now boasts publishers, retailers, distributors and technology companies from around the world, including organizations based in France, Germany, Norway, U.S., Canada, China, Korea, and Japan. In addition, in February 2014 the first Readium.org board was elected by the membership and the first three projects being developed by members and other contributors are all nearing "1.0" status. The first project, Readium SDK, is a rendering "engine" enabling native apps to support ePub 3. Readium SDK is available on four platforms-Android, iOS, OS/X, and Windows- and the first product incorporating Readium SDK (by ACCESS Japan) was announced last October. Readium SDK is designed to be DRM-agnostic, and vendors Adobe and Sony have publicized plans to integrate their respective DRM solutions with Readium SDK. A second effort, Readium JS, is a pure JavaScript ePub 3 implementation, with configurations now available for cloud based deployment of ePub files, as well as Readium for Chrome, the successor to the original Readium Chrome extension developed by IDPF as the
  • Gary Edwards on 05 Apr 14
     
    excerpt/intro: Last month marked the one-year anniversary of the formation of the Readium Foundation (Readium.org), an independent nonprofit launched in March 2013 with the objective of developing commercial-grade open source publishing technology software. The overall goal of Readium.org is to accelerate adoption of ePub 3, HTML5, and the Open Web Platform by the digital publishing industry to help realize the full potential of open-standards-based interoperability. More specifically, the aim is to raise the bar for ePub 3 support across the industry so that ePub maintains its position as the standard distribution format for e-books and expands its reach to include other types of digital publications. In its first year, the Readium consortium added 15 organizations to its membership, including Adobe, Google, IBM, Ingram, KERIS (S. Korea Education Ministry), and the New York Public Library. The membership now boasts publishers, retailers, distributors and technology companies from around the world, including organizations based in France, Germany, Norway, U.S., Canada, China, Korea, and Japan. In addition, in February 2014 the first Readium.org board was elected by the membership and the first three projects being developed by members and other contributors are all nearing "1.0" status. The first project, Readium SDK, is a rendering "engine" enabling native apps to support ePub 3. Readium SDK is available on four platforms-Android, iOS, OS/X, and Windows- and the first product incorporating Readium SDK (by ACCESS Japan) was announced last October. Readium SDK is designed to be DRM-agnostic, and vendors Adobe and Sony have publicized plans to integrate their respective DRM solutions with Readium SDK. A second effort, Readium JS, is a pure JavaScript ePub 3 implementation, with configurations now available for cloud based deployment of ePub files, as well as Readium for Chrome, the successor to the original Readium Chrome extension developed by IDPF as the
Gary Edwards

ODF vs. OOXML: War of the Words | Andrew Updegrove: Tales of Adversego - 0 views

updegrove.wordpress.com/...odf-vs-ooxml-war-of-the-words

ODF

shared by Gary Edwards on 16 Mar 14 - No Cached
  • Gary Edwards on 16 Mar 14
     
    "For some time I've been considering writing a book about what has become a standards war of truly epic proportions.  I refer, of course, to the ongoing, ever expanding, still escalating conflict between ODF and OOXML, a battle that is playing out across five continents and in both the halls of government and the marketplace alike.  And, needless to say, at countless blogs and news sites all the Web over as well. Arrayed on one side or the other, either in the forefront of battle or behind the scenes, are most of the major IT vendors of our time.  And at the center of the conflict is Microsoft, the most successful software vendor of all time, faced with the first significant challenge ever to one of its core businesses and profit centers - its flagship Office productivity suite. The story has other notable features as well:  ODF is the first IT standard to be taken up as a popular cause, and also represents the first "cross over" standards issue that has attracted the broad support of the open source community.  Then there are the societal dimensions: open formats are needed to safeguard our culture and our history from oblivion.  And when implemented in open source software and deployed on Linux-based systems (not to mention One Laptop Per Child computers), the benefits and opportunities of IT become more available to those throughout the third world. There is little question, I think, that regardless of where and how this saga ends, it will be studied in business schools and by economists for decades to come.  What they will conclude will depend in part upon the materials we leave behind for them to examine.  That's one of the reasons I'm launching this effort now, as a publicly posted eBook in progress, rather than waiting until some indefinite point in the future when the memories of the players in this drama have become colored by the passage of time and the influence of later events. My hope is that those of you who have played or are n
Gary Edwards

Microsoft Will Support ODF! But Only If It Doesn't 'Restrict Choice Among Formats' - 0 views

www.betanews.com/...1181922127

ecma-376 interoperability iso marbux microsoft odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.
  • Gary Edwards on 12 Dec 07
     
    Incredible comment by Marbux!  With one swipe he takes out both Ecma 376 and ODF. 

    Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard.  ODF was approved by ISO nearly a year ago.

    Criticizing Ecma 376 is easy.  It was designed to meet the needs of  a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms.  It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.

    Criticizing ODF however is another matter entirely.  Marbux points to the extremely poor ODF interoperability record.  If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.

    The "many vendor" aspect of OpenOffice is somewhat of a scam.  The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun.  Which is exactly the case with MSOffice.  With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!

    The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory.   Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0.  All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.

    Here are some thoughts i wou
Gary Edwards

Between a rock and a hard place: ODF & CIO's - Where's the Love? - 0 views

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

cio government microsoft oasis odf officeopenxml ooxml opendocument openxml

shared by Gary Edwards on 12 Dec 07 - Cached
  • So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence. After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators.    And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
  • Gary Edwards on 12 Dec 07
     
    Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


    Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


    The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


    Andy puts it this way, "
      

    And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
    As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe
Gary Edwards

Open Document Foundation Gives Up | Linux Magazine - 0 views

www.linux-magazine.com/...n_document_foundation_gives_up

cdf odf ooxml w3c

shared by Gary Edwards on 12 Dec 07 - Cached
  • The reasons for the move to CDF was improved compatibility with Microsoft’s OOXML format the foundation claimed at the time. Cris Lilley from W3C contradicted. CDF is not an office format, and thus not an alternative to the Open Document Format. This turn-down is likely the reason for the abrupt ditching of the foundation.
  • Gary Edwards on 12 Dec 07
     
    I've got to give this one extra points for creativity!  All anyone has to do is visit the W3C web sites for CDF WICD Full 1.0 to realize that there is in fact a CDf profile for desktops.  CDF WICD Mobile is the profile for devices.

    My guess is that Chris Lilley is threading the needle here.  IBM, Groklaw, and the lawyer for OASIS have portrayed the Foundation's support for CDF WICD Full as a replacement for ODF - as in native file format for OpenOffice kind of replacement.  Mr. Lilley insists that CDF WiCD Full was not designed for that purpose.  It's for export only!  As in a conversion of native desktop file formats.

    Which is exactly what the da Vinci group was doing with MSOffice.  The Foundation's immediate interest in CDF WICD was based on the assumption that a similar conversion would be possible between OpenOffice ODF and CDF WICD.

    The Foundation's thinking was that if the da Vinci group could convert MSOffice documents and processes to CDF WICD Full, and, a similar conversion of OpenOffice ODF documents and processes to CDF WICD could be done, then near ALL desktop documents could be converted into a highly interoperable web platform ready format.

    Web platform ready documents from OpenOffice?  What's not to like?  And because the conversion between ODF and CDF WICD Full is so comparatively clean, OpenOffice would in effect, (don't go native file format now) become ahighly integrated rich client end user interface to advancing web platforms.

    The Foundation further reasoned that this conversion of OpenOffice ODF to CDF WICD Full would solve many of the extremely problematic interoperability problems that plague ODF.  Once the documents are in CDF WICD Full, they are cloud ready and portable at a level certain to diminish the effects of desktop applications specific feature sets and implementation models.

    In Massachusetts, the Foundation took
Gary Edwards

Wizard of ODF: OASIS invited to join Microsoft in the DIN technical report - harmonization effort. Will they take the bait? - 0 views

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

din eu harmonization iso oasis odf ooxml xml

shared by Gary Edwards on 29 Jan 08 - Cached
  • the WG is busy working on a first draft. This'll include mainly work in Wordprocessing. Spreadsheet and Presentation is still in the very early work. So help from the ODF TC would be great --- and a liaison would make sense IMHO. To give you an idea why help from the ÓDF TC would be needed I'll briefly outline some questions which arose: * Need for more use-cases, i.e. feasable interop scenarios * Discussions of unspecified behaviour (e.g numbering in 1.0, spreadsheet formulas, compatibilty options, etc.) and their impact on interop scenarios * Questions regaring generic settings like e.eg. form:control-implementation="ooo:com.sun.star.form.component.Form", or tweaking a la http://www.openoffice.org/issues/show_bug.cgi?id=51726. * Possible interop problems not handled by the specs (e.g. graphics, WMF, EMF, SVM, etc.) or e.g. font metrics and font embedding. As you see there are a lot of overlapping areas with eg. the "ODF interop" we dealt with in the workshop in Barcelona. [This issue is hosted in the Adoption TC, right? Maybe this TC is also suited as a liaison partner?]
    • Gary Edwards
      Gary Edwards on 29 Jan 08
       
      Uh Oh. Microsoft and Novell joined the EU's call to harmonize ODF and OOXML, but Sun and IBM refused the invite. Now we have the invite in front of the OASIS ODF TC!. Is there any rock big enough for them to hide under if they also refuse?
      And if the OASIS ODF does join the EU-DIN-ISO effort, where doe stha tleave IBM, Sun and their inistance on a politically mandated "rip out and replace" as the only acceptable solution?
Gary Edwards

How Microsoft Ratted Itself Out Of Office | Michael Hickins | BNET - 0 views

industry.bnet.com/...ft-ratted-itself-out-of-office

MSOffice-productivity michael-hickins google-wave ooxml

shared by Gary Edwards on 15 Jul 09 - Cached
  • Gary Edwards on 15 Jul 09
     
    Another good article form Michael Hickins, this time linking the success of Google Wave to the success of Microsoft OOXML. Rob Weir jumps in to defend , well, i'm not sure. I did however respond. Excerpt: Developers hoping to hitch a ride on Google's Wave have discovered that Microsoft may have unwittingly helped them resolve the single greatest problem they needed to overcome in order to challenge the dominance of Office. When Microsoft set out to create Office 2007 using a brand new code base - Office Open XML (OOXML) - it needed to accomplish two goals: make it compatible with all previous versions of Office, and have it accepted as a standard file format for productivity tools so that governments could continue using it while complying with rules forcing them to use standards-based software. ..... Depending on your perspective, either Microsoft has sowed the seeds of its own undoing, or international standards bodies succeeded in forcing Microsoft to open itself up. Either way, Microsoft has given away the key to compatibility with Office documents, allowing all comers to overcome the one barrier that has heretofore prevented customers from dumping Microsoft's Office suite.
Gary Edwards

Jive Buys Microsoft Office Collaboration Plugin OffiSync For Up To $30 Million - 0 views

techcrunch.com/...-offisync-for-up-to-30-million

msoffice wikiWORD jive-OfficeSync

shared by Gary Edwards on 23 May 11 - No Cached
  • Gary Edwards on 23 May 11
     
    excerpt: OffiSync offers a a plugin for Microsoft Office that serves as a bridge between Office and Google Docs. When it first launched, the app's primary feature was to save Office documents to your Google account. It's since integrated Google Image Serach into Office, and added support for Google Sites. The application allows you to do Office-to-Office collaboration, and you can also have users editing the same document from Google Docs' online interface. Changes aren't synced as you type in each character, but rather each time you hit the 'save' button. Offisync is offered under a freemium model, but recently tweaked its pricing to offer more free features. Jive's CEO Tony Zingale says that this is a game changing acquisition for Jive, which combines computing with social collaboration to offer fully-featured social networks for businesses. Its suite of applications help businesses collaborate on a variety of tasks, including holding discussions, communication, sharing documents, blogging, running polls, and social networking features and more. "With OffiSync, Jive has the opportunity to become the most widely adopted Social Business platform for over 600 million Microsoft users, giving them the ability to bring social to the way they work.
Gary Edwards

Microsoft preps Office 365 document management tool for lawyers | Network World - 2 views

www.networkworld.com/...nagement-tool-for-lawyers.html

wordSDK Office-365

shared by Gary Edwards on 19 Aug 14 - No Cached
  • The product apparently has a special search engine that can be accessed from within Outlook and Word, and it offers functionality to “track or pin” frequently used documents and “matters,” those issues related to managing a law practice. Emails can be dropped into the appropriate context from Outlook, and documents retain their metadata, permissions and version control as they’re stored and shared.
  • Gary Edwards on 19 Aug 14
     
    "Microsoft has developed a document management add-on for Office 365 intended for lawyers, signaling a possible interest by the company in creating vertical-industry tools for the suite. Featured Resource Presented by Riverbed Technology 10 Common Problems APM Helps You Solve Practical advice for you to take full advantage of the benefits of APM and keep your IT environment Learn More Microsoft announced the product, called Matter Center for Office 365, Monday, saying it's in limited preview and available via a beta program to which customers can apply. The company provided few details about how the product works and what features it has, focusing instead on the fact that it is closely integrated with Office 365. Customers will be able to use Matter Center from within the suite's interface and components, like the Word and Excel apps, the SharePoint Online collaboration server and the OneDrive for Business cloud storage service. Matter Center has been designed to let lawyers and other legal professionals "easily find, organize and collaborate on files" within Office 365, instead of having to use a separate document management product. It remains unclear whether Matter Center will have all the security, compliance, retention and search functionality of full-featured document management products already used in legal settings."
  • Paul Merrell on 19 Aug 14
     
    Big barrier in that vertical market; law firms are required by Bar disciplinary rules to protect the confidentiality of client files. Unless Microsoft implements end to end encryption for Office 365 so that it's nigh impossible for the NSA et ilk to gain access to the plain text and rewrites its end user license to guarantee confidentiality of customer files, MSFT will get only the unwary law offices to use Office 365.
Gary Edwards

Munich reverses course, may ditch Linux for Microsoft | Network World - 0 views

www.networkworld.com/...ditch-linux-for-microsoft.html

WordSDK Office-365

shared by Gary Edwards on 19 Aug 14 - No Cached
  • Reiter has also criticized the city’s open-source initiatives since his election, saying that the technology sometimes lags behind that of Microsoft, and that compatibility issues can cause issues.
  • The news comes just eight months after Munich’s city council essentially declared victory, saying that the LiMux transition was complete and boasting of more than $15.6 million saved since the project began. Nearly 15,000 users were converted to the city’s customized Linux-based operating system.
  • Gary Edwards on 19 Aug 14
     
    "The German city of Munich, long one of the open-source community's poster children for the institutional adoption of Linux, is close to performing a major about-face and returning to Microsoft products. Featured Resource Presented by Riverbed Technology 10 Common Problems APM Helps You Solve Practical advice for you to take full advantage of the benefits of APM and keep your IT environment Learn More Munich's deputy mayor, Josef Schmid, told the Süddeutsche Zeitung that user complaints had prompted a reconsideration of the city's end-user software, which has been progressively converted from Microsoft to a custom Linux distribution - "LiMux" - in a process that dates back to 2003."
Gary Edwards

Online brochure maker by pub HTML5 is available online for everyone - WhaTech - 0 views

www.whatech.com/...-available-online-for-everyone

HTML5 HTML5-CSS3-JavaScript

shared by Gary Edwards on 28 Dec 15 - No Cached
  • Gary Edwards on 28 Dec 15
     
    "The press release introduces detailed capabilities of PUB HTML5's online brochure maker. The software is developed for people to prepare brochures online easily. PUB HTML5 is a leading publishing destination suitable for business owners, non-profit organizations as well as individuals. Whether you have a small scale business or a huge multinational company, you can certainly depend on PUB HTML5 for digital publishing. It is an open access HTML5 Digital Publishing Platform that allows you to convert PDF, MS Office and Open Office documents to HTML5 and jQuery based publications at no cost at all. These features make your flipbook even more attractive for the customers. Anna Lee, the chief designer of PUB HTML5 has announced a new online brochure maker (http://pubhtml5.com/digital-brochures-maker). It would make brochure designing simpler for the users. With the help of this software, you will be able to customize your catalogs, brochures and magazines online. More than six lakh users rely on PUB HTML5 for online publishing. The content published using the software program is compatible with all leading computers, laptops, tablets and mobile interfaces. Operating Systems like Android, iOS and Windows 8 also support this software quite well."
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

OOXML in Norway: The haywire process | Geir Isene : Straight talk on IT - 0 views

blogs.freecode.no/isene

interoperability iso odf officeopenxml ooxml opendocument

shared by Gary Edwards on 12 Dec 07 - Cached
  • I had read the essay by Jon Bosak (SUN Microsystems) on why SUN voted as it did in the US. He lays out a very different strategy. His view is that the battle is lost to completely reject OOXML as an ISO standard. ISO can only reject it with comments, and that is equivalent to giving Microsoft a todo-list on how to fix the draft so as to get it approved. Microsoft has sufficient manpower to easily tackle that. Most of us had missed what Mr. Bosak saw: OOXML promises interoperability with earlier closed binary formats (the Word Doc, older Excel file formats etc.). But it doesn’t deliver. How on earth could someone be able to convert old binary files to the new format without having the specification of the old formats and a mapping to OOXML. If you are to translate some text from Chinese to English, it doesn’t much help to only know English.
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point.
  • “Ah c’mon Bosak, you are chickening out, we must stop this dead in the track”
    • Gary Edwards
      Gary Edwards on 12 Dec 07
       
      There you go Geir!

      Sun and Bosak have held the door open for MS-OOXML since 2002, when Sun blocked an effort to write the ODF Charter to include as a priority, "compatibility with existing file formats". This of course would include the billions of legacy MS binary documents.

      The thing is that those who work in the conversion-translation field will tell you that it is currently impossible to pipe converted legacy binary documents and OOXMl docs for that matter into ODF. Just as Microsoft claims, ODF in it's current state is insufficient and unable to handle the rich feature set of the MSOffice developers platform.

      The problem could of course be easily fixed by the inclusion in ODF of five structural generics. In the past year, there have been no less than five iX "interoperability enhancement" proposals submitted to the OASIS ODF TC for discussion and consideration. As uber universal interop expert Florian Reuter points out in his blog, these iX proposals did not fare so well.

      What Florian doesn't point out is that it was Sun who opposed any and all efforts to improve compatibility with existing Microsoft binary and OOXML documents. Just as they have done for nearly five years now.

      Sort of puts the Sun-Bosak support for ISO approval of MS-OOXML in a different light. ~ge~
  • Gary Edwards on 12 Dec 07
     
    see the sticky notes on this one
Gary Edwards

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

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

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

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

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

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

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

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

    While they celebrate, Microsoft is quie
Gary Edwards

Microsoft's 'Men in Black' kill Florida open standards legislation - 0 views

enterprise.linux.com/article.pl

odf odf-legislation officeopenxml ooxml opendocument openxml politics

shared by Gary Edwards on 12 Dec 07 - Cached
  • Rep. Homan and his son Doug tried to add their little open standards boost to SB 1974 as quietly as possible. They wanted the modified bill to at least get through its first committee approval before anyone spotted what they had done. But Microsoft's Florida lobbyists were on the ball and spotted it almost immediately. "It was like the movie 'Men in Black,'" says Rep. Homan. "Three Microsoft lobbyists, all wearing black suits." Another lobbyist (unaffiliated with Microsoft) who would speak only "on background" laughed at the "Men in Black" description. "I know those guys," he said. "They even wear sunglasses like in that movie. They are the 'Men in Black' of Florida lobbying, for sure." A legislative staff employee who would lose his job if he were quoted here by name said, "By the time those lobbyists were done talking, it sounded like ODF (Open Document Format, the free and open format used by OpenOffice.org and other free software) was proprietary and the Microsoft format was the open and free one." Two other legislative employees (who must also remain anonymous) told Linux.com that the Microsoft lobbyists implied that elected representatives who voted against Microsoft's interests might have a little more trouble raising campaign funds than they would if they helped the IT giant achieve its Florida goals.
  • Gary Edwards on 12 Dec 07
     
    It seems Microsoft has blocked another attempt by concerned legilators to mandate open file formats for governemnt information.  Good read with some great quotes.  The legislation passage itself is extremely well written.
1 - 20 of 45 Next › Last »
Showing 20▼ items per page