There were 5 successive Roundtables. Each roundtable was led by 5 short presentations before the topic was opened to the floor for general discussion. The first roundtable focused on "What is ODF, and why are open document standards important". There were many questions regarding how open standards affect competition and innovation, whether ODF is in fact the best standard, issues of archiving and interoperability with ODF as well as how ODF addresses/will address concerns of accessibility for disabled persons.
The second Roundtable discussed how various software developers were responding to ODF and the third roundtable focused on whether governments or non-governmental and consumer organizations should systematically use procurement policy to promote ODF. The following roundtable was a lively discussion on whether national or global "agreements" can play a role in promoting ODF and how. During that roundtable as well as the last one on "Reflections and next steps", there were discussions of future work and strategies on ODF in a new international forum, the Internet Governance Forum (IGF) to be held in Athens, Greece, October 30 - November 3, 2006.
2More
Home - Berkman Center for Internet & Society - 0 views
-
-
Gary Edwards on 15 Dec 07The Berkman Center for Internet & Society at the Harvard Law School held an Open Document Conference, October 23rd, 2006. Just a few weeks after the October 4th, 2006 resignation of Massachusetts CIO Louis Gutierrez. This is the summary report of organizer Manon Ress. Sam Hiser represented the OpenDocument Foundation. The ZERO Interop problems that plague ODF implementation were not discussed. Strangely :) Another point not discussed is the fact that ODF is not an Internet file format. It's a desktop office suite only format. This constraint is written into the ODF charter. Interestingly, one of the problems of making ODF Web ready is that of highjacked W3C standards. Highjacking occurs when a specification or application takes existing W3C standards and changes the namespace reference to it's own. This is what ODF does. The reason for doing this is to constrain and limit the W3C standard to just those aspects implemented by the ODF reference application, OpenOffice. XForms, SVG, SMiL, XHTML, RDF/XML and RDFa are problematic examples of W3C namespaces that have been highjacked by ODF to meet the specific implementation constraints of OpenOffice. This impacts developers who rely on standard libraires to do conversions and processing. The libraries are built to the proper W3C namespace, and unfortunately assume that ODF complies. It doesn't, So developers have to investigate how OpenOffic eimplements XForms and SVG, and build special ODF libraries before they can use ODF on the Web. It can be done, i think. But it's a train wreck of a mess guaranteed to destroy the high level of web interoperability users and developers expect.
-
1More
Microsoft-led Forum Yields Tools for OOXML Interoperability - Business Center - PC World - 0 views
-
Is there nothing that can cool the flames of this document war? Interesting coverage of the recent OOXML Interoperability event in London (Monday). Real stuff not talk. Since Florian, Jason and i are working on an OpenWeb ready HTML+ layer riding over OOXML there are some things mentioned that look very interesting. ..."An Opera browser plug-in for Open XML Document Viewer v1.0 was released at the meeting; the tool provides direct translation for Open XML documents (.DOCX) to HTML, enabling access to Open XML documents from any platform with a Web browser, including mobile devices. The document-viewing software already includes a plug-in for Firefox, Internet Explorer 7 and Internet Explorer 8...." ..."Microsoft and the other participants in Monday's forum also made available a beta of Apache POI 3.5, a Java API (application programming interface) to access information in the Open XML Format....."
1More
shared by Gary Edwards on 12 Dec 07
- Cached
Can't We All Just Get Along? - 0 views
www.gcn.com/...45014-1.html
ecma iso microsoft ms-ooxml oasis odf officeopenxml opendocument openxml
![](/images/link.gif)
-
Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.
IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.
With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.
Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.
In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.
Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing doc
2More
ODF Civil War: Bulll Run - Suggested Changes on the Metadata proposal - OASIS ODF - 0 views
-
From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF 1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, < http://ec.europa.eu/idabc/en/document/6474/5935>. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance. As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.
-
This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata. It's a treasure.
There is one problem with marbux's statement though. We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC. This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006. Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.
The ODF iX enhancements were essential to saving ODF in Massachusetts. Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.
For nearly a year we tried to push through some semblance of the needed iX enhancements. We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.
Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition.
Still rather than fork ODF, we are simply going to move on.
On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.
In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.
Since then we've moved on to CDF, the W3C Compound Document format. Incredibly, CDF is able to do what ODF can not. With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere.
The challenge for these g
1More
Microsoft's Open Source Strategy & The Yahoo bid to get back in the game - 0 views
-
On the morning of February 1st 2008, Microsoft announced an unsolicited bid of $44.6B hostile for Yahoo!, and by the end of the day, Microsoft had lost $20B in market capitalization. Where does this leave Microsoft's open source strategy and the analysis thereof? Yahoo! was a pioneering "internet company", one of the first to really create and capture value of a world newly web-enabled. And like many of these so-called internet companies (Google was another), Yahoo! built it infrastructure on open source technologies. Why? Better, faster, cheaper: Dave Filo and Jerry Yang were still poor college students back in the day, but smart. (As were Sergey Brin and Larry Page, but that's another story.)
3More
Interoperability, choice and Open XML - spot the odd one out - 0 views
-
Excellent summary from Edward Macnaghten. It all comes down to this: OOXML is designed entirely to extend the Microsoft Desktop Monopoly, leveraging that monopolist control into server systems, devices and the future of the Internet
-
Excellent summary from Edward Macnaghten. It all comes down to this: OOXML is designed entirely to extend the Microsoft Desktop Monopoly, leveraging that monopolist control into server systems, devices and the future of the Internet
-
Excellent summary from Edward Macnaghten. It all comes down to this: OOXML is designed entirely to extend the Microsoft Desktop Monopoly, leveraging that monopolist control into server systems, devices and the future of the Internet
3More
shared by Gary Edwards on 12 Dec 07
- Cached
Microsoft Hit By U.S. DOT Ban On Windows Vista, Explorer 7, and Office 2007 - Technolog... - 0 views
www.informationweek.com/...showArticle.jhtml
exchange/sharepoint government msoffice odf opendocument standards vista vistachain vistastack
![](/images/link.gif)
-
» E-Mail » Print » Discuss » Write To Editor late last year -- can be resolved. "We have more confidence in Microsoft than we would have 10 years ago," says Schmidt. "But it always makes sense to look at the security implications, the value back to the customer, and those kind of issues." The DOT's ban on Vista, Internet Explorer 7, and Office 2007 applies to 15,000 computer users at DOT proper who are currently running the Windows XP Professional operating system. The memo indicates that a similar ban is in effect at the Federal Aviation Administration, which has 45,000 desktop users. Compatibility with existing applications appears to be the Transportation Department's major concern. According to a separate memo, a number of key software applications and utilities in use in various branches of the department aren't Vista compatible. Among them are Aspen 2.8.1, ISS 2.11, ProVu 3.1.1, and Capri 6.5, according to a memo issued by staffers at the DOT's Federal Motor Carrier Safety Administration. Any prolonged ban on new Microsoft technologies by the federal government could have a significant impact on the software maker's bottom line, as Microsoft sells millions of dollars in software to the feds annually. http://as.cmpnet.com/event.ng/Type=count&ClientType=2&AdID=125682&FlightID=75634&TargetID=2625&SiteID=222&AffiliateID=283&EntityDefResetFlag=0&Segments=1411,3108,3448,11291,12119&Targets=2625,2878,7904,8579&Values=34,46,51,63,77,87,91,102,140,222,227,283,442,646,656,1184,1255,1311,1405,1431,1716,1767,1785,1798,1925,1945,1970,2217,2299,2310,2326,2352,2678,2727,2767,2862,2942,3140,3347,3632,3636,3638,3890,3904,4080,448
-
Whoa, those government desktops add up quickly. This Vista ban will immediately effect over 50,000 desktops, with tens of thousands more possibly impacted by the IE 7.0 ban. The MS Exchange/SharePoint Hub juggernaut is based on IE 7.0, which is not available for Windows 2000 - MSOffice 2000 desktops.
Lack of Vista Stack compatibility with non Microsoft application is given as the reason for the ban. But notice the "alternatives" to Vista mentioned; Novel SuSE and Apple Mac. What kind of interop - compatibility do they offer? My guess is ZERO!
The reality is that the DOT is trapped. My advice would be stay exactly where they are, keeping the current MSOffice desktop installs running. Then, install the Foundation's daVinci ODF plugin for MSOffice.
This will insure that Windows OS and MSOffice bound business processes can continue to function without disruption. Win32 APi based applications like those mentioned in the article can continue. Critical day to day business processes, workgroup and workflow related activities can continue without disruption or costly re engineering demanded by a cross platform port.
What daVinci doe sdo is move the iron triangle that binds Windows-MSOffice applications to business processes and documents, to an ODF footing. Once on a ODF footing, the government can push forward with the same kind of workgroup - workflow - intelligent docuemnt - collaborative computing advnaces that the Vista Stack was designed to deliver. Only this push will involve the highly competitive "the customer is sovereign" environment of ODF ready desktop, server, device and Web 2.0 systems. End of Redmond lock-in. End of the costly iron triangle and the force march upgrade treadmill that so enriches Microsoft.
So what's not to like? We can do this.
~ge~
http://docs.google.com/View?docID=dghfk5w9_20d2x6rf&revi
2More
shared by Gary Edwards on 12 Dec 07
- Cached
Microsoft Closer on &#0092;'Office Open&#0092;' Blessing - 0 views
www.internetnews.com/...3662681
ecma exchange iso microsoft msoffice oasis odf ooxml opendocument openxml sharepoint vista xml
![](/images/link.gif)
-
Opponents to OOXML, which include IBM (Quote) and the Open Document Foundation, have argued that Microsoft's specifications are unwieldy and that the standard application is redundant with the Open Document Format (ODF), which already exists. Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address different needs in the marketplace," the company wrote in an open letter published earlier this month.
-
Internet News is reporting that Ecma has submitted to the ISO/IEC JTC1 their repsonsess to the 20 "fast track" for Ecma 376 (OOXML) objections. Nothing but blue skies and steady breeze at their back for our friends at Redmond, according to Ecma's rubber stamper in chief, Jan van den Beld.
Once again there is that ever present drum beat from Microsoft that ODF can't handle MSOffice and legacy MSOffice features - including but not mentioned the conversion to XML of those infamous billions of binary documents:
"Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address diffe
4More
shared by Gary Edwards on 12 Dec 07
- Cached
Brian Jones: Open XML Formats : Office Open XML final draft!!! - 0 views
blogs.msdn.com/...final-draft_210021002100_.aspx
drawingml eooxml imported:del.icio.us msoffice odf vml xml
![](/images/link.gif)
-
# re: Office Open XML final draft!!! @ Wednesday, October 11, 2006 1:46 PM The past incarnations of DrawingML have been chaotic. It would be interesting, out of curiosity, to get an accurate history of what changed over time, perhaps to better understand what is supported in what. Here is my take, I am pretty sure I got at least 50% of it wrong :-) - pre-Windows 95 era, Word, Excel and Powerpoint use their own vector drawing layer used to draw shapes, pictures, diagrams, art and charts. Powerpoint, acquired by Microsoft in 1987, has by far the advanced drawing layer (bi-linear gradients, opacity, ...), codenamed Escher (in reference of the famous mathematician). - In Office 95, it is decided to reuse the Powerpoint vector graphics layer in Word and Excel. Migration begins. - Migration ends with Office 97 where both Word, Excel and Powerpoint use the same vector graphics layer, publicly known as MSO (mso97.dll) - In Office 2000, it's all craze about internet and Word tries to export WYSIWYG html. For that end, mark up extensions must be added to account for the MSO drawing layer. Hence the VML (Vector Markup language). Excel and Powerpoint don't support it. Internet Explorer natively supports VML (Internet Explorer's Direct animation vector drawing layer dismissed for performance reasons). - In Office XP, VML migration ends and both Word, Excel and Powerpoint support VML whenever a document is saved as a "Single web page archive" (.mhtml extension). - In Office 2003, nothing changes. - In Office 12, MSO gets rewritten with backwards compatibility in mind. The vector drawing layer uses more sophisticated drawing functionalities which makes it easier to draw themed, 3D realistic objects. Technically, the differences are akin to the differences between GDI and GDI+. This new shared library is known as E2O and the corresponding mark up language is known as Drawing ML (Ecma TC45 specs). - In Office 14, ??? perhaps the drawing layer is rewritten, again, to 1) use WPF 2) to allow plugins, hence enabling much more sophisticated do-it-yourself scenarios. Use cases : custom charts ; BI analysis tools. Stephane Rodriguez
-
Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
-
Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
-
Stephen Rodriguez gives a quick history of the MSO <> VML <> DrawingML transition in the Microsoft Product line. Note that MSOffice produces two versions of EOOXML file formats. On import os a legacy document, MSOffice will convert the doc and produce a
2More
People Use The Cloud And Don't Even Realize It - Business Insider - 0 views
-
Stats on Cloud usage shows that only 29% of Internet users are using a cloud service. One of the charts provided shows that iCloud (Apple) and DropBox have over 300 million users. Microsoft OneDrive has come out of nowhere to claim the third position with 250 million. And Google Drive finishes in fourth place with 200 million. Funny that Google would be so short when gMail and Chrome have proven to be so successful. And gDOCS was a pioneer of cloud based editing of productivity documents. Office 365 has only been available on iOS since May, yet look at the numbers! Incredible. Oh, Box is also listed in fifth place with 25 million users. I'm starting to think that DropBox, RackSpace and Egnyte are in big trouble. Microsoft is on a huge roll, and my gut instinct is that they have some kind of a deal going with Apple iCloud and Office365. Amazon is surprisingly missing.
-
Stats on Cloud usage shows that only 29% of Internet users are using a cloud service. One of the charts provided shows that iCloud (Apple) and DropBox have over 300 million users. Microsoft OneDrive has come out of nowhere to claim the third position with 250 million. And Google Drive finishes in fourth place with 200 million. Funny that Google would be so short when gMail and Chrome have proven to be so successful. And gDOCS was a pioneer of cloud based editing of productivity documents. Office 365 has only been available on iOS since May, yet look at the numbers! Incredible. Oh, Box is also listed in fifth place with 25 million users. I'm starting to think that DropBox, RackSpace and Egnyte are in big trouble. Microsoft is on a huge roll, and my gut instinct is that they have some kind of a deal going with Apple iCloud and Office365. Amazon is surprisingly missing.
11More
Why Microsoft Azure could have the last laugh in the cloud wars | CITEworld - 0 views
-
Venture capitalist Brad Feld recently wrote an interesting post predicting the end of Amazon's dominance of the cloud computing market, and concluded, "it’s suddenly a good time to be Microsoft or Google in the cloud computing wars." I'd go one step farther. Using Feld's arguments, I'd say that Microsoft is in the driver's seat. More like this The dark side of the cloud price wars between Amazon, Google, and Microsoft The rise, fall, and rehabilitation of Internet Explorer Microsoft, Apple, and Google battle for the mobile enterprise Featured Resource Presented by Citrix Systems 10 essential elements for a secure enterprise mobility strategy Best practices for protecting sensitive business information while making people productive from Learn More First, the price war. Microsoft and Google are on approximately equal ground when it comes to cutting prices -- both have highly profitable core businesses that they can use to subsidize a price war in cloud infrastructure, even to the point of sustaining losses for a while to gain market share. Amazon does not.
-
Second, the quality argument. Like Feld, we've also pointed out that there are niche cloud providers that do a better job than the big guys at providing infrastructure-as-a-service for specific verticals, but when you move all the way up the stack to full software-as-a-service applications, Microsoft has an edge among the big three with Office 365.
-
Google has been making inroads into smaller businesses with Google Apps for almost a decade now, Microsoft remains the standard in the biggest and most profitable business customers -- as this recent investigation from Dan Frommer at Quartz showed, only one company in the Fortune 50 uses Google Apps. (That company happens to be Google itself.)
- ...8 more annotations...
-
But then comes the fourth argument. Feld points out that once companies get to $200,000 per month of cloud-infrastructure spend, it's actually significantly cheaper to build their own data centers
-
The third argument, support, is mostly a wash. While Amazon's support may be terrible (I have no evidence of this, but I'm taking Feld's word for it), Microsoft and Google and their respective ecosystem partners do a decent job of supporting customers on their stacks.
-
It's unclear how the Google Cloud Platform helps that business. Are customers using Google's cloud somehow more likely to advertise with Google? I don't see it. Are Google advertising customers demanding to run other workloads on Google technology? I don't see it.
-
There's one more point favoring Microsoft. Google's core business is selling online advertising. That business makes up about 90% of Google's revenue, and it has enviably high operating margins -- around 30%, based on Google's 2011 financial report. (I picked 2011 because that was before Google bought Motorola Mobility, which changed the margin structure.)
-
Microsoft is the only one of the big three players with an on-premise offering -- Windows Server and the rest of the Microsoft infrastructure family. Maybe the exact break-even point will change as the cloud price wars continue, but Microsoft has the most pieces customers would need to move from all-cloud to a hybrid or on-premise solution. Or, for that matter, for existing on-premise customers to begin experimenting moving some workloads to the cloud.
-
Meanwhile, while Azure almost certainly offers lower margins than, say, on-premises Windows Servers, it's necessary -- customers are moving workloads to the cloud, and Microsoft needs a competitive offering there to keep them on the Microsoft stack so they continue to buy other Microsoft products. Plus, as I argued in point four, today's Azure customers could become tomorrow's on-premise Microsoft infrastructure customers.
-
In other words, Microsoft Azure and Google Cloud Engine both lower the profit margins of their parent companies. But Azure is clearly strategic while Cloud Engine, as far as I can tell, is not. Who's more likely to keep investing in and improving its cloud?
-
right now, Microsoft's chances look pretty good to me. No wonder they put the cloud guy in charge of the company.
18More
shared by Gary Edwards on 12 Dec 07
- Cached
Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views
www.microsoft-watch.com/...obla_de_oba_da.html
odef odf officeopenxml ooxml opendocument vista-stack
![](/images/link.gif)
-
To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
-
OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.
The binding model for OOXML is "Smart Documents", and it is proprietary!
Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.
Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.
Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.
I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.
Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.
One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.
This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
-
-
Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
-
The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.
Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!
So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.
So where is an Open Stack model to turn to?
Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.
OOXML is unfi as a UFF becuase it is application - platform and vendor bound.
For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.
XHTML+ (XHTML + CSS3 + RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML+. Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML+?
I think so. But we can't be sure until the da Vinci proves this conclusively.
One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.
So why not try it with XHTML+, or ODEF (the eXtended version of ODF en
-
-
Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
-
This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.
The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.
The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!
This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.
Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.
It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.
With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF +), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.
MSOffice 2007 i
-
- ...6 more annotations...
-
Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.
-
True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".
In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.
Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!
It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.
So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.
-
-
Microsoft got there first to protect Office.
-
No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!
Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.
The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.
The Vista Stack looks like this:
..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub
..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End
The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.
The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.
The productivity gains that can be had through this migration to the E/S Hub are extraordinary.
A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)
These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emer
-
-
Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.
-
By adapting XML
-
The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!
In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.
Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.
Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.
Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.
When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!
The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.
Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
-
-
Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
-
Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.
What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.
Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
-
-
I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.
-
Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.
The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.
One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.
Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows + MSOffice + VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.
The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.
On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.
Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.
-
2More
Brendan's Roadmap Updates: My @media Ajax Keynote - 0 views
-
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.
-
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!
-
4More
A Fresh Cup » About - 0 views
-
Then I got fed up with Microsoft. It took about fifteen years, but I finally reached the point where, no matter how good some of their software was, or how well-meaning some of the rank and file employees were, I could no longer stomach the corporate policies. You can read more about that in my posts What’s Going On Here?, The Rest of the Story, and The Examined Software Life. Certainly, reasonable people can disagree on these things, but for me, working with Microsoft tools and technologies is no longer an option. So I quit.
-
Same here. For me the 1996 JavaONE Conference was a great reunion of former Windows - Microsoft Developer Network members i had not seen since the old OS2-Windows Conference days. It was clear to me then that much of the Internet wave surge back then was charged by developers and investors dissaffected with Microsoft and the Windows monopoly. What people at that first JavaONE Confernece were looking for was a means to convert the Interent into a full fledged computational platform; augmenting the ubiquitous communications, access and exchange grid with web ready applications. They sought an alternative to Windows platform development. One of the more prominent memes back then was provided by the rather small but vocal FOSS developers community attending the conference. They had this strong belief that much of the value of the Internet was captured in this phrase, "Owned by none, used by all". For anyone familiar with the abusive monopolist's tactics, the meme was quite resonant. So much so that the openness of Java became a serious issue dooging Sun for years. I've always thought Sun paid an iincredible price for the reprehensible business practices of Microsoft. In early times, Java would have rode the same wave of application developer take up that Windows enjoyed in the early 90's. The monopolist however had changed the rules forever. And that's actually a good thing. Thanks for writing about your journey Mike. I'm looking forward to your blogervations.
-
2More
shared by Gary Edwards on 12 Dec 07
- Cached
BetaNews | ECIS Accuses Microsoft of Plotting HTML Hijack - 0 views
www.betanews.com/...1169824569
dirtytricks iso microsoft msoffice oasis odf ooxml opendocument openxml xml
![](/images/link.gif)
-
Nonetheless, from ECIS' perspective, the lone enemy is at the gate: "With XAML and OOXML," stated ECIS attorney Thomas Vinje, "Microsoft seeks to impose its own Windows-dependent standards and displace existing open cross-platform standards which have wide industry acceptance, permit open competition and promote competition-driven innovation. The end result will be the continued absence of any real consumer choice, years of waiting for Microsoft to improve - or even debug - its monopoly products, and of course high prices."
-
There you go! The Micrsoft plot to take over the Internet in a nutshell, with XAML and EOXML at the point of the spear.
Funny how everyone knows what Micrsoft's intentions are, even having identified the tehcnoliges to be used, but still no one can stop them. How did this recidivist reprobate get so outside the rule of law and beyond the reach of good men?
EOXML (MS Ecma 376) must be stopped at ISO/IEC, if only to slow down this worldwide train wreck they plan for our beloved and open Internet.
2More
shared by Gary Edwards on 12 Dec 07
- Cached
Most Business Tech Pros Wary About Web 2.0 Tools In Business - Technology News by Infor... - 0 views
www.informationweek.com/...showArticle.jhtml
exchange iso microsoft msoffice oasis odf ooxml opendocument openxml sharepoint vista xml
![](/images/link.gif)
-
How should an IT team start thinking about an Enterprise 2.0 strategy? One way is to carve it into two main areas. The first is Web-based information sharing--think business versions of Wikipedia, MySpace, and Flickr. A sizable minority of companies are finding effective business uses for blogs, wikis, syndicated feeds, pervasive search, social networking, collaborative content portals like SharePoint, and mashups that use easier-to-integrate APIs and fast-response development techniques such as Ajax. One example: Wikis, which let multiple people access and edit a document online, are widely used at 6% of companies in our survey and used effectively by a few employees at 25% of companies. The second area is voice and messaging, where voice over IP, instant messaging, presence, videoconferencing, and unified communications can make it possible to connect people in more relevant ways. Unified communications entails the blending of voice calls, video, and messages, coupled with functionality like embedded click-to-call links in documents and contact lists and the ability to see if colleagues and partners are available to chat. It's widely used at 13% of companies surveyed and effectively by a few at 24%.
-
Great coverage from InformationWeek about the emerging Enterprise 2.0 arena. Author Michael Hoover does not get too deep into the Information Processing Chain, as exampled by the integrated Vista Stack of desktop, server, device,Internet systems and services. But he provides a more than adequate framework for evaluating chain components.
As the ODF - OOXML battle contiues to expand, engulfing swallowing and swamping near everythign in it's path, the day is not too far off when the battle will move to the center of Enterprise 2.0 considerations. It has to. XML Hubs are how these converging technologies are going to be gathered, integrated and configured to impact rapidly changing business processes. There has to be a universal transport in these systems that all applications can work, and nothig matches the highly portable and interactive document/data capabilities of ODF and OOXML. They alone own the desktop prodcutivity environment migration to XML. And it will be through XML - RDF/XML that the Hubs finally integrate the flow of information between desktops, servers, devices and Internet systems.
~ge~
1More
shared by Gary Edwards on 23 May 11
- No Cached
A New Patent Application from Apple Introduces us to a Breakthrough Platform Independen... - 0 views
www.patentlyapple.com/...ndependent-word-processor.html
apple-patent browser-wordprocessor layout-engine
![](/images/link.gif)
-
excerpt: This could be Apple's new internet strategy that thrusts more of us into the next phase of what is now known as the Post-PC era. In my view, this breakthrough could be a game changer. The Problem to Solve The recent proliferation of web browsers and computer networks has made it easy to display the same document on different computing platforms. However, inconsistencies in the way fonts are rendered across different computing platforms could cause the same document to be rendered differently for users of different computing platforms. More specifically, for a given font, the way in which metrics for various font features are interpreted, such as character height, width, leading and white space, can differ between computing platforms. These differences in interpretation could cause individual characters in a document to be rendered at different locations, which could ultimately cause the words in a document to be positioned differently between lines and pages on different computing platforms. This inconsistent rendering could be a problem for people who are collaborating on a document. For example, if one collaborator points out an error on a specific line of a specific page, another collaborator viewing the same document on a different computing platform may have to first locate the error on a different line of a different page. Hence, what is needed is a technique for providing consistent rendering for documents across different computer systems and computing platforms. Apple's patent application describe a system that typesets and renders a document in a platform-independent manner. During operation, the system first obtains the document, wherein the document includes text content and associated style information including one or more fonts. The system also generates platform-independent font metrics for the one or more fonts, wherein the platform-independent font metrics include information that could be used to determine the positions of i
1More
Google Makes it Easier to Dump Microsoft Office #io14 - 0 views
-
"At I/O, Google always seems to find a way to squeeze the fun from Microsoft's master plan to rule the business world. This year, the 'something' comes in the ability to edit Microsoft Office documents in Google Docs. At face value, it doesn't seem too serious. But when you stand back and look at it, it takes on far more significance than first impressions convey. Who Needs Office? Equally important is the fact that Google Docs enable users to open Word, Excel and PowerPoint files, make changes and then save them onto the Google cloud in their native formats. By enabling users to edit Office documents through the cloud-based platform, it removes one of the biggest obstacles to Google Docs adoption. It also puts Google right up there with Microsoft Office as an option for enterprises looking for a business productivity suite. OK, we know. Microsoft Office has a lot more punch than Google Docs or even Google Apps, offering all kinds of functionality that Google still hasn't introduced. But Google Apps is still cheaper than Office 365 - and in light of this week's Outlook.com outage, it is probably looking a lot more attractive, especially to those who couldn't access their emails. It is also worth remembering that, as we saw in April, a lot of business users are using only limited functions in Office and could quite happily dump it, take up Google Docs and still work away without any problems. In fact, the research by SoftWatch showed the average employee spends only 48 minutes per day in MS Office programs, and most of that time is spent on Outlook. Other Office application use usually occurs for viewing and light editing purposes, with only a tiny portion of the workforce identified as heavy users. The new editing functionality Google is offering is also available for mobile devices along with offline support that means that users can work away on their documents even when they are out of mobile reach and have the changes uploaded once they
50More
shared by Gary Edwards on 07 Nov 13
- No Cached
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
![](/images/link.gif)
-
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).
-
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.
-
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.
-
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.
-
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
-
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".
-
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