It was December, 2008, and I was in New York City. I went there for the exciting Adobe InDesign and InDesign Server CS4 SDK Post-launch Developer Briefing and I think that’s where I first met Roger, Heath, and Ferdinand face to face. All brilliant, wonderful people, but honestly I was not used to east coast time and between that, my lack of sleep the previous night, and the ambiance of the sedate library they had chosen for the event, I almost fell asleep in the beginning of the briefing.
One thing, however, woke me up.
Heath was iterating through changes to the SDK from CS3, and there had been a major re-architecture: linking. There was, now, a URL-based linking model. Really??? I was no longer sleepy.
When I had encountered InDesign 1.0 9 years earlier, I had lamented that referenced assets must always reside locally, in the local file system or on a network share. This meant that moving around InDesign documents between environments: desktop to server, Mac to PC, would quite often involve re-linking things, and we had helped numerous organizations automate the tedious process of moving things around, re-linking via scripting, and generally managing what I thought was a weakness of the application from the beginning.
So here it was, URL-based linking, and Heath explained that it wasn’t quite exposed within the application, but was fully available to automation via plugins. The general architecture looked great, and they even had some documentation about how to build plugins that would use this cool new feature. Links could even be bi-directional. I was determined to put this to work.
However, our attempts over the next few months didn’t really pan out. We were then much more skilled in ExtendScript and we assumed that it was our lack of plug-in sophistication that was at fault. After a few attempts failed, we moved on to other more attainable tasks.
Two years later, though, circumstances changed quite a bit. In late 2009, in a moment when Flash appeared poised to take over the universe (before Steve Jobs’ “thoughts on Flash”), Adobe had a moment of silliness when they decided to gut the InDesign engineering team (out with the old, in with the new?), and right when our Silicon Designer product was taking off, demanding just that sort of talent, our company was transformed by an influx of engineers better than we had ever imagined. Even Heath himself began working for us.
A dream come true, and I remembered this guy, Heath, and I had a chance to really get to the bottom of why this hadn’t worked before. Certainly now we had some plugin chops, what with the programmers who had built InDesign working for us. When a large photobook company asked us, “can you integrate with our DAM?” I said “boy can we….” thinking there was definitely a way we could get this to work. It was, after all, a feature of the product exposed to plugin automation.
It was funny, though, when we got into really prototyping it. It wasn’t truly usable; it had almost been exposed to automation, but there were header files that were used by Adobe when they used this features internally (which to my knowledge was only done with Version Cue and Buzzword integration), which made it only truly attainable with more of the source of InDesign than was made available with the SDK. We begged Adobe for the header files we needed.
I was passionate about this, I think anyone who has done so much work to make file-based links work in the real world has to be excited about it. We went so far as to track down Michael Easter himself, who wrote the linking architecture and who knows InDesign linking like nobody else. Michael got it to work, and I thought it would be so well-understood in the publishing world that our Silicon Connector product would take over the world over night. I guess the time frame was a bit optimistic, this was 2 years ago.
The first implementation was a success: we made the HTTP linking work in the context of a Day CQ implementation, customizing the state updater and link handler to work with the CQ5 DAM. I felt that this would be a great thing for Day or for any other DAM.
I was surprised by the responses I got when I explained the Silicon Connector technology to people. At its core, it simply made the http links work, yet there were two initial responses when I showed the technology:
Among the rabid enthusiasts, half of them actually understood what the technology did and appreciated it for what it was; the other half thought that this was a foundational thing that could solve a much bigger problem of some sort, for example two-way data binding with XML data sources, that sort of thing. Yes, it can be a part of such larger-scale solution, but at its core what we built mainly managed using HTTP instead of the file system to manage linked assets. Personally, I felt this was quite compelling on its own.
One of the people who was enthusiastic and appreciative of the more fundamental meaning was Jason Bright, leader of MediaBeacon. Jason had just as much excitement as I did, and we embarked on an effort to build a product together that gave end users an end-to-end solution that uses this feature and extends it with some server-side invention of Jason’s. He did also have plenty of creative ideas for the layers on top of this.
The product that MediaBeacon announced today, MediaBeacon Publishing, is the first DAM-based product based on Silicon Connector, and I believe it will be very valuable for many organizations. I am grateful to have met Jason and his team at MediaBeacon and thankful that Michael and others from Adobe have stuck with it, and that Adobe themselves have been so supportive. Things don’t always happen overnight, but vision and effort do pay off in the long run.
I was finishing up a very busy week this past Friday, when I got an email from Ed Kotnik – “Congrats on Best of the Best at XMPie Conference.”
This was for an application we built some time ago, but one that is very dear to my heart: our Silicon Paginator implementation for Royal Caribbean Cruise Lines. We worked very hard on this, and it represented a stage in the evolution of Silicon Paginator that was important to me at the time, and is still relevant to our future.
There are many cool aspects of this application, but what I think most significant is the pure InDesign Server automation that renders the very high-quality output from very complex data, following a structure-to-style mapping that lets InDesign templates format content from (mainly) XHTML structures into output that looks hand-crafted. Also the way it was built was a significant step up from the ways we had done this before, as we took on this project right after hiring one of the first in a string of top-notch software engineers that has joined us the past few years, and he took my crude hacks of years earlier on the processing and built it out the right way with more modern technology.
The Royal Caribbean implementation of Silicon Paginator represents the culmination of earlier work with XHTML as a data source for InDesign Server applications. One particular project that had a great deal of similarity was the content management system we built for ACTS Seminaries, and attempted to productize as “Instacatalog” in 2003. This was prior to InDesign Server, but at the time we automated InDesign desktop for catalog output. The application worked by ingesting XHTML, parsing it with a stream parser (then SAX-based) and analyzing each node of content to determine its structural context to render it in InDesign in the correct style, given style mappings between the CSS for the web and the InDesign object styles for print. That application and others like it worked quite well, but I had hacked them in fairly precarious ways. In particular, the processing wasn’t elegant at all.
Despite the lack of elegance back then, it was impressive how well it worked. The one limitation (still a limitation) is that it didn’t handle absolutely arbitrary structures: you could put a list inside a list, but only so many levels deep, for example. Yet it was able even then to validate and reject cases where users would try to go outside of such limitations. And it seemed whatever structures anyone needed, it was easy enough to extend.
With Royal, it had to scale. The volumes were huge, there was certainly not going to be any manual inspection of things. We were fortunate to have more product-level developers working with us, and the whole transform piece was refactored to work very efficiently. Template setup was fairly manual, though we had some utility scripts that were helpful and we developed some straightforward setup guidelines. These days we are much better at tooling the document setup aspect of this sort of application.
The text-intensive, tables flowing across pages form of output with sources like this is still in the minority in Silicon Paginator implementations. More commonly we have relational data sources, with only crude markup from within database fields, producing directories and catalogs more than heavy stories of rich text, but here in applications like this are the fun part. How far are we going? Do we merge cells? Lists within lists within tables? Tables within lists with tables? It is fun to gain control over the transformation between different forms of rendition, with HTML posing some unique challenges and opportunities. While Royal may enjoy the tangible benefits of automated publishing, I enjoy the technical details in seeing what I had personally cobbled together 10 years ago get transformed by real developers into a truly reusable set of tools.
For ten years I have been automating Adobe InDesign, and for 10 years I have had to deal with assets that were exclusively on the file system. InDesign won’t generally let you link to an asset on the web.
When I first met InDesign, in 2000, I (like many users then and since) thought maybe URL-based assets would be a feature that was already part of this then-new product: wouldn’t it be cool to work with web-based assets? But no, it wasn’t part of the product, and such a feature wasn’t necessarily essential to getting work done. With InDesign and InDesign Server, you just have to make sure things are in the right place on the file system. WebDAV offers a sort of linking to Web-based assets, but it is typically clunky and for the most part we put effort into moving files around and validating that they are in the right place when we automate InDesign Server.
In February, 2009 I went to cold New York City to attend the “Adobe InDesign and InDesign CS4 SDK Post-launch Developer Briefing.” I was tired and almost slept, but I woke up when they said how the linking architecture had been fundamentally rewritten underneath, to support URI-based linking, two-way linking, and generally what looked like anything one would want to do with linking. I asked, immediately, “can this be scripted?” and was quite disappointed to find out that it not only required a plug-in to leverage any of this power, but there was quite a bit left to developers to create what one would imagine as a basic use of URI-based linking.
Still, I never forgot this, and recently we finally had a chance to build our own plug-in to exploit this underlying capability. After taking some time to figure out how to do this right at a low level, thanks to some truly expert developers, it works!
With what we are calling “Silicon Connector” we can interface InDesign with DAMs (so far Day CQ5 and MediaBeacon, but looking at others), Rendition Systems (Scene7), and generally any remote asset. We are working on specific implementations that already validate improvement in authoring workflows, but there are a wide range of possible use cases:
This capability compliments and enhances the CS Extensions that came out with InDesign CS5. We now have what we naively expected out of InDesign 1.0. Better late than never!
Seeing the range of possibilities and finding different visions and functional requirements of different DAM vendors and developers/users, I see now why Adobe left this capability so far under the hood. There is not a single generic approach that would work for everyone.
With the release of Scene7 5.0 and its Web-to-print features, there are now two extremely powerful server-side rendition technologies from Adobe. Unless you are intimately familiar with these two technologies and their corresponding branches of the Adobe organization, you might assume that Adobe would develop these technologies with some concept of integration, but in truth they really are two distinct and disconnected offerings that just happen to come from the same parent company.
When Adobe bought Scene7 in May of 2007, Scene7 was a leading provider of imaging for retail web sites, known for feeding up images on demand so users could zoom in on a purse, rotate a watch with pseudo-3D technology, or see a furnished room as it would look with various selections of colors and materials in a photo-realistic way. The scalable, hosted application would serve up images in different raster formats at different resolutions based on the parameters of a URL. While it was possible to produce raster images of sufficient quality for print, they did not produce vector-based output, nor did they have a strong text engine, so Scene7 at the time was unsuitable as a complete solution for web-to-print. Rather, it would typically serve up images that would be used by other tools (server software with robust PDF output such as InDesign Server or Quark DDS) to the extent that Scene7 images became part of print output.
Meanwhile, InDesign Server was a very different sort of application, available as software that users would put on their own servers (not a hosted solution: initially the license even prohibited use within a Software as a Service or SaaS model). There was very little “server” in InDesign Server, instead the core rendition part of the desktop application was split out from the UI and handed off to the developer community with a simple SOAP interface and no job queuing: it was up to us developers to figure out how to spawn instances, queue jobs and make it produce output as fast as was possible given the slow nature of the rendition engine. In the five years of desktop product evolution, emphasis had been on attaining ultimate rendition capability more than speed of composition. InDesign Server went exponentially slower than earlier server-based composition engines, because it offered very robust features that were computation-intensive. Using the InDesign Paragraph Composer to lay out text, for example, involves analyzing the entire paragraph before deciding where to place the second character. The complexity of rendition, coupled with a lack of initial high-throughput focus, means that InDesign Server offers the ultimate in quality of output, at the expense of throughput.
Soon after Adobe bought Scene7, they embarked on adding web-to-print functionality to the product. There was some interaction with the InDesign Server group, even some involvement in Scene7 Professional Services in InDesign Server deployments, but fundamentally Scene7 went down the path of building their own web-to-print by pulling Adobe core technology into their server-based application infrastructure. They opted to base web-to-print on a new XML format that was brewing at Adobe since the Macromedia acquisition: FXG. FXG was a graphic format being built into Flash and Flex, which could be exported and imported from Illustrator; the primary motivation/use case for FXG was Flash Catalyst, which uses this model to enable powerful designer/developer workflows. The XML nature of the graphics and the integration of this XML into Flex MXML as a “native” format provide a good foundation for defining relationships between graphic objects and their behaviors in Flash applications. Notably, Flash Catalyst didn’t really require print-related functionality, so FXG did not (and still does not) include much that supports print: the color model is exclusively RGB, for example.
The first Scene7 Web-to-print release, in September of 2009, used FXG 1.0. In order to provide capabilities essential to print output that were not part of the FXG 1.0 specification, FXG was extended by a Scene7 namespace, thus “Scene7 FXG” is the core XML used to describe the high-quality print output from Scene7 Web-to-print. FXG 1.0 was put out concurrent with a wonderful new text markup language, the Text Layout Framework (TLF). Unfortunately, at the time of FXG 1.0, the TLF spec was not yet final. The text possible with the first Scene7 Web-to-print, even with S7-namespace enhancements, offered only rather crude text features. This made the first Web-to-print offering from Scene7 less than stunning for text: it was clear, however, that the core rendition functionality was solid, and there were some exciting aspects of the system from a Web-to-print standpoint:
With the first, FXG 1.0-based release, there was a core infrastructure for Web-to-print, but the application was clearly brand new, and the text capabilities were sorely lacking. Knowing that TLF 1.0, an extremely robust typographic capability, would be part of FXG 2.0, most of us in the development/partner community decided to wait for the release based on FXG 2.0. This wait turned out to be longer than expected, because FXG 2.0 itself suffered from delays in Flex 4 and what became a desire/policy of synchronizing Flex 4 with the CS5 release. Once FXG 2.0 was final, though, Scene7 was quick to make it work with the system: in parallel, what had been the Solution Accelerator was divided into an SDK and a sample application, and improvements were made to document setup and other aspects of Web-to-print based on experience with 1.0 and beta 2.0 implementations. In October 2010, the Scene7 5.0 / FXG 2.0 Web-to-print went live on all Scene7 production servers.
Now that there is a truly robust Web-to-print offering from the Scene7 group, the comparison with InDesign Server, which is at this point a well-proven rendition back end to Web-to-print, can be made. And it should be made… already in our work at Silicon Publishing, we have been in the middle of decisions over which technology to use several times. At a very high level, there is a high degree of overlapping capability, and the buzzword popular at Adobe the past couple years, “disruptive” is well-suited. Adobe is definitely competing with itself, and it is not as trivial as the PageMaker/InDesign “disruption” when you know one technology is slated for extinction: it is likely that both Scene7 and InDesign Server will continue as Adobe offerings indefinitely, and both products will continue to grow and mature. In the overall industry, these two are the leaders from a functional standpoint, as Adobe has such a huge advantage over their competition in this space. So let’s look at the differences, first in a side-by-side comparison:
|Feature||Adobe Scene7 Web-to-print||Adobe InDesign Server|
|Hosting model||Software as a Service (SaaS)||Off the Shelf Software|
|Speed||Very fast at generating PDFs and previews, suitable for real-time response to edits||Latency to generate previews, not generally suitable for real-time response to edits. Our solution with Silicon Designer is to render all edits directly in Flash, though there are challenges with this and some limitations.|
|Composition capability||Robust text, not quite as robust as InDesign but functionally quite amazing, see the core text features at the Adobe Labs TLF Demo. Still limited to core text something like InDesign 1.0: no bullets/lists built in, no tables, primitive span across pages. However, these features are also current limits of the Flash player, yet are on the roadmap for the Flash player, and there are ways to accomplish these with custom development.||Completely robust composition capability. The state of the art, with absolute fine-grained control over anything you might ever do with composition. Yet in a web-to-print context, it is difficult to round-trip those features that don’t exist in Flash.|
|Appropriate document types||Small page count, without heavy flow across pages: Business cards, brochures, letterhead, stationary, greeting cards. The scope of document type is expected to extend over time, though there has not been a clear statement from Adobe Scene7 that they have an aim for long documents.||Any type of document, though the speed of rendition can be a negative factor with very-fast throughput documents such as statements.|
|Web-enablement||Designed from the ground up to be part of a web solution: scalable, flexible, and easy to connect with other Scene7 core imaging capabilities.||This is the desktop InDesign application, put on a server, with minimal server-like features. It can work in a web context and is proven in numerous systems, yet it can mainly be considered a headless InDesign exposed to SOAP and CORBA interfaces.|
|Maturity||Brand new – only in October 2010 is there a version out with truly robust text. Indications are that it will generally work, and the Scene7 development team is the best/most responsive in the world, but there will be some inevitable iteration to reach maturity.||Completely proven: released on October 2005, numerous deployment churning out many documents worldwide. Based on the ubiquitous InDesign engine.|
|Integration with the Creative Suite||It is a one-way street into FXG from the CS application (InDesign, Illustrator, or Photoshop) in which you author your templates. There are some document features that won’t make it into FXG with fidelity, and there is no lossless round-trip back to the CS format: Illustrator imports straight FXG, with some caveats and without the S7 namespace features. Once it is in Scene7, you would generally work in Scene7 for all edits and post-processing, unless you want the ugly prospect of opening up a PDF in Illustrator or the limited straight FXG import happens to meet your needs.||Complete round-trip with InDesign desktop. Integration with other CS tools works well in terms of referenced .ai or .psd assets, but unfortunately there is no Illustrator or Photoshop server with which to accomplish robust online edits to these assets.|
|Print-centric features||“Just enough” print features, this is likely to extend as it is used in real world situations. CMYK color, PDF job options, trim and bleed settings, are all available, yet there are still some limits.||All of the robust print-centric features of InDesign.|
|Sample Application||Basic Web-to-print sample available with the Solution Accelerator SDK/Sample application: most true implementations will still require extensive development. The system is flexible and open, Scene7 chose not to prescribe much as it will be used for diverse workflows/document types.||No real example full solution: samples such as the Distributed Copy Editor have some full-scope Web-to-print implications but are outliers compared to typical web-to-print scenarios. Emphasis in the samples is on the server side of things.|
|Core rendition approach||Scene7 expects you to know in advance the structure of pages and blocks on those pages: automation is accomplished via passing FXG to the server describing a complete graphics tree for each page||InDesign Server offers complete control over the rendition, passing a script to the server which can include scripts that deal with pagination, how things flowed, etc.|
We can also look at the areas where Adobe Scene7 is ideal, or where InDesign Server is ideal. Constraints such as availability to host yourself vs. availability in a SaaS model may eliminate one or the other off the bat.
assuming that your document types are relatively small and straightforward, i.e. business cards, stationary, signage, brochures, multi-page documents in the low page-count range or where the design is not flow-intensive.
Those are the strong indicators that would push it one way or another, although there are requirements driven by workflow/UI and or document characteristics that can push it one way or another.
I will try to keep this updated, please provide feedback based on your experience, or questions that might help make this more clear. In general, both tools are very powerful, and there is something like a 70% overlap, whereby in 70% of the Web-to-print solutions we’ve encountered, either one would work, so it is likely we will work with both for the foreseeable future. Our Silicon Designer product is built to run with either Scene7 Web-to-print or InDesign Server (optionally with XMPie on top of it), and we are planning to continue to support this.
One thing to contemplate that also keeps coming up in our work: could they be combined? Yes, they definitely could… this will inevitably happen for some large organizations, but a formal connection is not currently on Adobe’s roadmap as far as we can tell. We would like to see InDesign Server offered as a SaaS component of Scene7, but have no indication this is in the cards. There is nothing like an obvious combination, you would probably see one or the other at the center of such a combined solution: Scene7 just for previews from FXG, or InDesign Server just for long documents or specific document features, that sort of thing. It really depends on what you want to accomplish. Combining the two will probably be very rare unless/until Adobe offers some appropriate bundled pricing.
Here at MAX for the 5th year in a row – I didn’t go to these until Adobe bought Macromedia and it has been very interesting to see the changes over the past 5 years.
Keynote – Kevin Lynch started in with discussion technology trends, then moved into presentation of the Digital Publishing features. Wired magazine was presented, and really didn’t show much different than what we’ve seen already. They seem to have reacted to some of the initial bashing. They showed dynamic text wrapping in HTML, identical to SVG text wrapping demos from 10 years ago. Not exactly thrilling, though they do say they are contributing to WebKit. He presented the Adobe Digital Publishing Suite, starting from InDesign, collaboratively produced and distributed, and of course they want to use Omniture to analyze the results. It is quite a stretch to think they will do the full-cycle at all as well as they have built the low-level tools.
Kevin spoke of video… quite an awesome amount of video going out in Flash, but unlike last year they are not showing the trend towards ubiquity, but rather “most video on the web is still shown in Flash.” Flash 10.1 was very quickly adopted, apparently, yet we know where it did not show up. Internet television keeps advancing, and Flash does have quite a head start there: the streaming is really impressive. AIR for TV is out; first launch partner is Samsung. Marc Goldberg of Epix spoke of multi-screen, saying their subscribers watch on a number of different screens: the demo broke, however.
Flash Media Server is working on on-the-fly encoding. Wowza seems to have made some real inroads, based on discussion with some attendees. P2P-assisted video looks kind of cool.
Kevin showed a number of small apps built targeting the tablet computing environment… it would appear they are rewriting things to be more lightweight. He demo’d a table device / PC wireless app, where the iPad served as a palette for a user in Photoshop.
He spoke of the enterprise… the impact of multi-screen, as well as LiveCycle. He mentioned the Day Software acquisition, which we have been watching with eager anticipation at Silicon Publishing, and brought their CTO David Nüscheler to present.
David Nüscheler from Day spoke of the need for discrete control of how things work across devices: he explained that the communications are truly different, it is not as trivial as spewing forth variants of the same thing entirely, but there is a true need to have some separate content specifically targeted. David demo’d CQ5, showing editing of HTML and mobile content. He did not dwell on the DAM, which has been our primary interest in Day. We are in the midst of a very exciting integration with the Day DAM, and so far we have been extremely impressed with the DAM aspects of Day. Adobe has done several acquisitions really well, and even though it’s the LiveCycle group that they are subsumed into, we are optimistic they will take over appropriate leadership roles. Wouldn’t it be cool if we can connect the rendition power of Adobe to structured information in LiveCycle? We have witnessed a long and pathetic history of the Acrobat monopoly being squandered on silo-based random junk (Central Output Pro? Graphics Server? Document Server? Forms with dirt-crude formatting?…) for rendition, yet there is good security and DRM in LiveCycle, hopefully the Day team will gut it and connect appropriately to the rendition side of Adobe (Flash, After Effects, InDesign desktop and Server, and above all… Scene7).
Day does introduce a real philosophical paradox. After the keynote, they presented content that had probably mainly been presented before, starting with a 45-minute argument for Open Source. LiveCycle has traditionally been the precise opposite of Open Source, and just the day before at the leadership summit we had heard that the “open source” Flex project had approximately 0 contributions from anybody but Adobe: will Day change this? It will be interesting. It was sort of strange to hear conway’s law cited and consider what that would mean as the organization is not the Apache Foundation any more, it is Adobe. We will see some interesting software!
Kevin demo’d medical imaging technology. Flex really does create powerful front ends for enterprise apps. Flex 4.5 beta is out, I am not sure after the year of Flex 4 beta lifestyle how deeply we will want to dive in. Back then we really needed the TLF badly, so it was probably worth the rush, I think with future Flex betas we can build a bit less production code on top of it.
Mike Lazaridis, CEO of RIM, came on and showed the Blackberry Playbook. Adobe and RIM have been working together with Flash/AIR; fairly obvious that Apple motivates them. “Not trying to dumb down the internet for a mobile device” – NICE stab at Apple. That was, as the 2 of you who read this blog know, my big reaction to the iPad.
Kevin showed some cool games, rendition gets faster over time with more use of the GPU, and AIR is evolving. AIR for Android looks good, Apple has some good competition, hopefully. Deploying from Flash to iPhone OS is once again possible, too.
Social gaming has always been one of Kevin’s interests: he showed the work idol worship, a nice-looking virtual reality game that uses old school animation techniques coupled with slightly newer technologies. He showed some very cool GPU-accelerated 3D capabilities of other games. Flash is really getting nice: the virtual reality driving demo was compelling. With the next Flash 3D, code named Molehill, the immersive 3D graphics should be very good for games and general 3D imaging.
Chrysty Wyatt from Motorola came on to speak of Android and the request of Motorola to put Flash on mobile devices – “anyone who fails to put Flash on a mobile device is not giving you the Internet.” And they are not above bribing us – all attendees at MAX are getting a Droid 2.
..Should be a revolution for web-to-print applications. I would imagine that Facebook will further consolidate its control over the Social Media space. A bit scary that such critical mass factors leave MySpace, Friendster, etc. fairly dead in the water…. people want to go to where their friends are. And it appears more and more digital assets will reside in Facebook as well. I imagine that applications like fidipidi will get more popular as the quality of output from Facebook to print gets better.
I saw the feature yesterday, but it seems to have been turned off today. Maybe this has caught on? Today, I uploaded a 1936 × 2592 image, and as usual Facebook reduced it to 538 × 720.
Hardly conducive to high quality print, though I have been impressed that even with resolution along those lines, the cards from fidipidi have looked pretty great.
As soon as Facebook turns this feature back on, I will make a high resolution card using fidipidi and report the results.
DITA will take over the world… or maybe more like lay under it, as XML does currently.
From my perspective, DITA (or a good part of DITA – there is also the tech doc focus) is the next step in core SGML/XML. IBM started SGML itself, and later had a fair amount to do with XML: now the same sort of people are working on DITA, making XML safe for the world.
DITA extends SGML constructs such as entities with constructs such as conrefs. Everyone loves the idea of re-use of content, but XML 1.0 is a bit too flexible in this regard. It doesn’t say much about *how* you re-use, associate, and aggregate content, thus tools will do the same thing different ways, or won’t support re-use well at all. DITA fixes this, then immediately (concurrently) applies it to Tech Doc.
DITA is based on the practical experience of some IBM tech doc teams and while their goals and requirements were specific to tech doc, many of the core constructs are not.
Similar to XML itself, which is a meta-language (or language for creating languages), DITA has a powerful specialization methodology, that allows for completely custom document structures, yet a backwards compatibility with the core DITA constructs. If your <eBookPara> tag is read by a DITA rendition tool that only knows the <p> of DITA, you will at least get things rendered, though perhaps not in the special “eBook” way that you prefer. At least the tools don’t break.
It is somewhat confusing that the drivers for DITA remain squarely in the Tech Doc space, yet the solution it provides is often fairly universal. Maybe what DITA needs to do is split into the tech-doc specific DITA and the generic DITA, the way XSL split into XSLT and XSL-FO.
What is the world coming to? Never thought I’d see IE supporting SVG. We lobbied so hard 9 years ago, 8 years ago, and 7 years ago, until it felt like we were getting nowhere.
I remember Microsoft tried to hire me in 2002, having found me on the… SVG developers list. Now that was strange, what on earth were they doing stalking us XML geeks?
In a year or so, it became clear; XAML was highly derived from SVG, and would form the basis of WPF and Silverlight later. Unable to embrace a standard, MS had decided to copy standards activity into their own proprietary technology.
The poor SVG black sheep was even abandoned by Adobe itself when they eyed Macromedia/Flash, and enjoyed almost ZERO serious support over a few years, unless you count intensive emulation with XAML and later FXG, or the tireless efforts of a few diehards in places like the Mozilla project and Opera that kept SVG alive.
Fast forward 7 years, and we find Microsoft in the same boat with Apple, falling further behind Adobe’s Flash on the RIA front, with Silverlight piling up on the junkheap of obscurity along with Quicktime. With both proprietary efforts dead in the water, SVG is suddenly appealing to these would-be monopolies, and we find a bizarre rally behind a 10-year-old standard.
Why did they even bother to throw SVG into the mix with HTML5? Certainly the Canvas functionality can accomplish most or all of the core Flash capability that everyone (other than Adobe) wants. SVG and Canvas seem to have complimentary performance depending on what you’re doing. Still, who wants to learn how to do everything two different ways? Perhaps those railroading HTML5 through “spec” processes realize they won’t catch everything with the canvas approach, but more likely, they realize that this 2010 form of “standard” with Apple/Google pushing their rush “standard” out as Microsoft tails along, can have a better chance of flying with some stapled-on integrity from a bygone era.
It is still great to see, there is something really nice about the simplicity of core SVG, and it is fully ironic that its enemies have ended up having to support it despite their traditional opposition to standards. Apple, Google, Adobe, Microsoft have the same monopolistic agendas, yet are forced to co-exist, and let flowers like SVG grow through the cracks.
Today Steve Jobs called Adobe “Lazy.”
Flash has dramatically improved since Adobe bought Macromedia. Papervision 3D is a 3D engine that runs on Actionscript, this sort of capability was unheard of back when Macromedia ran Flash.
Flash is spreading all over the place: set top boxes, TVs, phones, everywhere except the iPhone. It is ubiquitous for ads and video on the web. No wonder Steve is jealous. What is the install base of Quicktime?
Flash runs fine on every other phone. Is the iPhone buggy? no, it is intentionally dumbed down in the interest of rabid monopolistic tendencies of one eccentric genius.
Steve should remember that Apple would have died save for its use as a graphics platform running Adobe technology for a long stretch of time.
The iPhone will be a better device when it supports Flash.
As much as he has done for the company and the world, Steve Jobs really has conquered everything that needed conquering; the world needs a little less conquering and fewer dumbed-down, closed-source, “no VM allowed” systems like the iPhone and iPad.
With the iPad we witness the first case in history of computing where the limitations of a small device float upwards into a bigger device, instead of the opposite (remember when Moore’s law was a good thing?): who is lazy?
I was on the phone with a prospective client today, who shall remain nameless and unidentifiable. This could be any company, as they face the essential predicament of anyone trying to get the same content to go to both web and print effectively.
On the one hand, there is so much commonality and re-use of their content across the web and print media, it is absurd to have two entirely different workflows. On the other hand, the tools that lend themselves to a real multi-channel workflow, such as real XML content management, take extreme effort and time to implement and often have expensive associated software. Even after that effort, authors or content sources may not fit in with the required content process at all. Beyond that, moving content over from an unstructured to a structured format can be really difficult.
Inevitably, XML demonstrations make business users underestimate the challenge. “If you show us something, show us with our content!,” he said; evidently they were shown a rosy picture where perfectly marked up XML flowed easily out into web, print, braille, video, whatever. It is true; if you have rich semantic markup the publishing capabilities are amazing.
The challenge is getting that richly marked up content. It is hardly automatic. The extreme best case for authoring such content is the world of technical documentation, where the authors are typically really technical, and highly-evolved schemas/toolchains like DITA give them guidance on how to structure content. But at the other extreme, with writers who are non-technical, it is hard to get them to work with tools that are too constraining, or to get them to follow rigorous guidelines. No pain, no gain: without the rich markup, publishing becomes more of a channel-by-channel basis.
I believe over time things will get easier, with standards like DITA, greater support for XML authoring in tools, and better example workflows for organizations smaller than the Department of Defense. But the pace of such improvement is slow.