Unleashing_power_white_paper

code
Mantra
DIGITAL PUBLISHING MADE MANAGEABLE
Contents
Contents
Re-Defining the Book and Its Publisher 2
The Changing Landscape 2
Why XML? 2
DTDs, Elements, Attributes, Entities – What is all of this stuff? 2
Document Type Definitions for Publishers 3
Deconstructing the Book 3
About Attributes and Entities 4
XML as a Single Source of Content 4
A Managing Editor’s Challenge 4
XML Change Management – A One to Many Relationship 6
ePub: An ebook Solution, but Not an XML Solution 6
XML: Bringing a Competitve Edge to The Publishing Process 6
The Instant Book – Back When… 7
An In-House Solution vs. an Outsourced Solution 7
Further Reading 8
Inquire Further of These codeMantra Software Solutions 8
Collection Point 8
pubXML 8
Universal PDF 8
Copyright ©2008 codeMantra LLC, All Rights Reserved
page
Re-Defining the Book and Its Publisher
G
one are the days when a book was simply a physical
assembly of folded and gather pages, bound as a series of
chapters in a case or paperback perfect binding. Gone
are the days when the only formats publishers had to concern
themselves with were hard cover, trade paperback or mass
market paperback. In today’s world a book can be a file format;
it can be content tethered to an application; a dynamic mashup of chapters, or selections of content from separate works,
published by separate houses. A book can be something rendered
on a reading device, shared across a social network, displayed
on a mobile phone or listened to on an MP3 player. Through a
myriad of new and evolving platforms, formats and devices the
book is being redefined. So too is the business of publishing.
The Changing Landscape
Publishers have never before faced such an overwhelming
cacophony of competitive information and entertainment
media. Network television & radio, boutique cable channels,
niche satellite radio, Web 2.0 social networks, blogs, PC and
console gaming, email services, internet video, RSS feeds, mobile
phone applications, traditional newspapers and magazines – plus
their growing counterparts on-line all compete for a potential
book reader’s attention. But while the ability to cut through the
clutter to reach a mass audience can be tough, thanks to the
pervasiveness of internet and mobile networks, niche audiences
have never been more accessible. And just as publishers embraced
the competitive media forms of television and radio to make
them effective marketing tools for their wares, so too have they
embraced the web and mobile networks.
The problem is publishers don’t always have what web-centric
audiences are looking for. Many a “connected” customer has
neither the time, inclination nor the patience for the acquisition
of a physical book – no matter how close the local bookstore, or
how “overnight” the shipping. More and more publishers have
to prepare their content for a wide range of formats, deliverables
and configurations. It might be that an industry lobbyist
discovers content within a searchable book that speaks to his
issue about rising cost of oil and its impact on healthcare. The
content has significant value to the lobbyist if he can re-publish
it to news group within 48 hours. Metadata steers the lobbyist to
the publisher and a rights manager. Terms of a deal are negotiated
in an e-mail exchange. But can the publisher deliver the content
within the next 12 hours in a format compliant with the lobbyist’s
RSS feed? Less than a decade ago, the delivery requirements for
such a sale would have been prohibitive for most publishers. And
even today, many would have to scramble to fulfill this order.
Subsidiary rights opportunities such as the one above are
becoming more and more prevalent, as publishers digitize their
content and make it discoverable through book search and online networks. With the increased exposure comes the demand
for content in many different formats. The dilemma for the
page
publisher is weighing the cost of converting content to multiple
formats and effectively managing the inventory, against a sketchy
return on investment. How can a publisher avoid the cost of
converting content to a format that becomes obsolete before he
can recoup his costs?
CONTENT MIGHT BE KING, BUT NOT IF IT REMAINS
INACCESSIBLE TO THE PEOPLE IT SERVES
By now, most publishers have heard claims that the solution
resides with XML (extensible mark-up language). But for many
XML is still an unknown. Many publishers wrongly view XML
as yet another format and that over time it too will be rendered
obsolete. This paper sets out to dispel some of the myths about
XML and demonstrate its utility in a changing publishing
environment, where content might be king, but not if it remains
inaccessible to the people it serves.
Why XML?
XML is simply a markup language, but why is it the markup
language of choice for publishers?
It is a markup language that is highly flexible and allows for
the addition and deletion of tags. XML is also referred to as a
metadata language; it consists of the tags that describe the content
– thus, <para> for paragraph or <body> for body text, <head> for a
heading. Identifying content components and their relationship to
one another goes a long way to making the content interoperable
between disparate devices and platforms. XML separates the content
from format. And while there are a couple of open source tools
involved, transforming XML content to a particular output
– HTML or XHTML (as used by the current ePub standard)
– can be a lot like applying a stylesheet to a word document.
Some conversions are nothing more than a reconfiguration of the
content to allow for the rendering capabilities or limitations of a
particular device or platform. By using XML as the source file,
pretty much any standard trade or academic book can be readily
converted to any number of digital outputs. We say the XML
content is interoperable, or that it’s platform agnostic, meaning the
content can be exchanged with all kinds of different application
programs and used by a variety of devices. It might be that certain
fonts are inaccessible to a particular application or that the nature
of the output dictates a different layout (one-column vs. multicolumn). That might change the look and feel of book content,
but the structure remains in tack. Chapter headings will still
render as distinct from the body text. So while rendering content
from an XML source might require some minor adjustments to
achieve an acceptable presentation, it is a far simpler exercise than
transforming that same content from a production file (Quark,
InDesign, FrameMaker, etc. ), or a composed PDF file, where the
format instructions are imbedded with the content.
Copyright ©2008 codeMantra LLC, All Rights Reserved
DTDs, Elements, Attributes, Entities
– What is all of this stuff?
Like any language, XML has its rules and parts of speech. The
DTD, or Document Type Definition, is the declared set of rules or
grammar, if you will, for a specific type of document. A single DTD
can define the structure for an entire class of publications. Across
most publishers’ catalogs a single set of rules can be established
that will govern how any book is put together. In the simplest of
examples, a novel might open with a short description of the author
(“about the author”); as with all books it must have a copyright page.
Perhaps this is followed by a foreword; next a title page; and then
the table of contents. From there, a series of chapters containing
text and possibly an illustration or two completes the structure.
This same basic model holds up for a work of non-fiction, with
the addition of some other elements – perhaps a prologue or an
author’s note. There could be insets of photographs with captions,
footnotes and endnotes. Add an appendix and an index and this
is a more complex structure than a novel. But in terms of XML
it just means more elements that have to be declared and tagged.
The DTD accounts for all of these elements; defines them and
establishes how they relate to each other. This gives each XML
document its structure. A valid XML document is one that adheres
to the structure or rules defined by the DTD.
Document Type Definitions for Publishers
There are a multitude of established DTDs and schemas available
to publishers – DocBook, NLM (National Library of Medicine
tag set), and TEI (text encoding initiative) to name just a few.
Some publishers (John Wiley & Sons, Random House, Pearson,
Penguin UK) have adapted DocBook to meet their needs. In
its open standard form, DocBook can be somewhat unwieldy,
given the structural requirements of most trade and academic
books and even a majority of textbooks. Other publishers,
such as Cengage have designed their own DTD. codeMantra
has developed a DTD it calls pubXML, which adheres to much
of the utilitarian structure of DocBook, but is much simpler
and better suited to the requirements of most book publishers.
Making the right choice about a DTD is all about analyzing
one’s book content and establishing what kinds of components
are required and how they are assembled to create each type of
book in a publisher’s list. This is known as modeling one’s data
(or content) and most publishers consult with an expert to have
this exercise performed. A publisher’s list may require more than
one DTD, but most trade and academic publishers find that a
single set of rules can be applied to all of their publications.
Deconstructing the Book
The term chunking is often used to describe the application
of XML markup to book publishing content. Indeed, when
transforming content to an XML structure, we are essentially
breaking the book down into components. The book is
deconstructed into fragments, which can then be recombined
to create new publications or reformatted to render as digital
publications on a PC, a reading device or mobile phone.
Chunking refers to the declared elements of the DTD. An
element can be a section, a chapter, a paragraph, a phrase or even a
single word. It can consist of text, an image, a table, any object or
combination thereof. Ultimately, these elements or chunks form
the building blocks within an XML document. The elements are
tagged. The tags form a granular level of metadata, which can
be used to query the repository and retrieve content appropriate
to other publications or applications. Given a wholesale XML
conversion of a publisher’s list, content is released from the
confines of the book model and made available for any form of
Figure 1 - In XML content chunks are tagged separately and made discoverable.
Book - Tag: ISBN/Title/Author/Subject/PubDate/extent
Section - Tag: ISBN/Title/Author/Subject/Topic
Inset of Photos - Tag: ISBN/Title etc.
CHAPTER
Chapter - Tag: ISBN/Title etc.
Paragraph - Tag: ISBN/Title etc.
Copyright ©2008 codeMantra LLC, All Rights Reserved
page
digital or print publishing or licensing. And yet, at any time a
production manager can call for the XML document associated
with a specific ISBN and expect to render the exact print-ready
PDF, P.O.D. or Postscript file required to print that title.
If we return to the earlier example of the lobbyist looking
to buy syndication rights for a single chapter, fulfillment is not a
problem. The chapter exists as a single XML instance. It is easily
retrieved from the publisher’s database and can be instantly
transferred into an RSS feed.
About Attributes and Entities
Attributes imbue the elements with specific or conditional values
and determinants. An attribute can define the specific source
for an element. For example, a graphic element can have an
attribute that identifies it as a gif image and tells the processor
where to find it. An entity is an alias for a particular piece of text
or component that gets used over and over. Take, for example, a
publisher’s boilerplate: it should be the same in all books. A text
entity comprised of the publisher’s legal name and address can be
stored in the data base with a specific name – ‘CorpID.’ When
an XML document calls for the entity ‘CorpID’ the publisher’s
boilerplate is referenced and rendered. The dynamics of these tools
is even more powerful, when one realizes that a change of address
need only occur in one file. Going forward all XML documents
referencing the ‘CorpID’ will render the new address.
A full description of these XML operators and how they interact
is beyond the scope of this paper. And while it is recommended
that the reader take a simple course in XML or peruse one or more
of the many books on the subject (see bibliography), a working
knowledge of XML is not essential to understanding its power and
essential role in digital publishing.
XML as a Single Source of Content
For more than a decade, proponents of digital publishing have
held out the promise of economies in production and distribution
efficiencies that would alter the course of publishing as we know
it. Certainly in other media, digital formats and digital delivery
have created an upheaval that could be characterized as nothing
short of disruptive. It could be argued that digital publishing
would have achieved meaningful traction long ago had there
been fewer offerings and a greater focus. Many publishers
complain that the space is still too crowded with a confusing
array of formats, devices and platforms. There are more output
options for publishers than any other media. Music labels can
effectively reach their entire consumer base with either a CD or
MP3 file. The movie and television studios have some options
when it comes to promotional formats, but the final product
is either in digital or analog production and a derivative DVD
product. Even the enormously successful console game industry,
faces only three significant formats (Nintendo, xBox and Sony
page
PS). And yet in publishing, the formats, the devices and the
options can be overwhelming. The following is considered a
conservative list of viable options:
1. Kindle (ePub through mobiPocket)
2. Sony Reader (ePub through Adobe Digital Editions and
BBeB)
3. iRex (iLiad)
4. mobi Pocket for (smart phones and mobile phones)
5. iPhone ( Stanza, ingests ePub)
6. Adobe Digital Editions (rich PDF s for PCs, Sony Reader
-- also ingests ePub)
7. PDF (image)
8. PDF (P.O.D.)
9. PDF (streaming- ebrary library solution)
10. PDF (Searchability -- Amazon, Google)
11. HTML (web browser applications)
12. Palm OS
And, still, there are the mainstays:
13. Print
14. Audio
No publisher should maintain versions for all of these outputs.
But depending on the title and audience, more than a handful of
these formats/platforms will apply. And even with the industry’s
promise of an ePub1 standard (a universally accepted XML
delivery format), the file structure required of deliverables for
each device (Sony Reader, Amazon Kindle) are just different
enough to necessitate separate files – separate SKUs.
A Managing editor’s Challenge
Back when print was the only format of concern, maintaining
up-to-date production files for a backlist and front list was
relatively simple. So simple, that many publishers relegated the
responsibility to their compositors or printers. Managing editors
might maintain a dedicated file system of editorial up-dates in
MS Word, but the source file for the most current, or accurate,
version was often a production file (InDesign, Quark). Until
recently, many publishers, relying on multiple in-house and outsourced designers, worked off sketchy records and third-party file
systems to locate up-to-date production files. Some publishers
(more than would probably care to admit it) manage physical file
systems of CDs, DVDs, and older forms of portable memory.
No such file “system” will weather the requirements of a digital
publishing operation.
Even publishers, with only a nascent digital publishing
program, are faced with managing four or five separate formats
for each ISBN – Print-ready PDF, Quark/InDesign, Image PDF,
P.O.D PDF and now ePub, mobiPocket, Adobe Digital Editions.
Given some form of a Digital Asset Management (DAM) system,
1 The International Digital Publishing Forum (IDPF’s) introduced this XML spec (ePub), in May
2008, and declared it the industry standard. The Association of American Publishers (AAP)
has since endorsed ePub as the standard delivery format for publishing content.
Copyright ©2008 codeMantra LLC, All Rights Reserved
the physical retention and retrieval of these formats is not a
problem. But managing up-dates and maintaining consistency
across all versions of a single title can take its toll.
Each correction or update can require multiple edit and
composition tasks. For a small list, with only a few digital offerings,
the burden is the equivalent of a nuisance. For a larger catalog of
titles, tied to an ambitious digital publishing program, managing
editorial changes becomes an onerous set of tasks, fraught with
errors and inaccuracies. Add to this, any contractual obligations to
maintain the editorial integrity of content licensed to third-parties
and the domino effect, of even minor changes, can be daunting.
As figure 2 illustrates, the traditional print production
process provides a reasonably effective routine for the rendering of
most print and PDF outputs. However, without the help of XML
mapping tools, standard production files (InDesign, Quark) are a
poor source, when it comes to producing some eBook formats, i.e.
ePub, BBeB, MobiPocket and web syndication formats. Where
publishers use multiple composition services, tracking down and
validating source files can be its own challenge.
Because XML separates format from content, it acts as a
neutral source file. It can be viewed as content in its purest state –
refined content! Without imbedded styles, XML content is readily
transformed or configured to almost any digital media output.
There are a myriad of XML tools (XPath, XPointer, XLink,
XQuery) that afford publishers unprecedented control and access
to their book content. None of these has greater utility than XSL
(XML stylesheet language) and XSLT (XML stylesheet Language
Transformation). Using these two applications, an XML engineer
can capture and preserve the stylistic preferences for any output.
When applied to an XML document, XSLT has the power to
transform a neutral XML file into one that will be compatible
with a target output or format and render content with prescribed
styles. Thus as we see in figure 3, a publisher who converts his
book content to XML and manages that XML as his single source
Figure 2 - Standard print production files aren’t easily rendered to
new eBook formats.
Figure 3 - From an XML source file all outputs are efficiently
rendered
Unedited Files
CS
Unedited Files
QXD
XML
Final Edited Files
PRINT
POD
IMAGE
ePub
ePub
ePub
Sony
Mobi
Kindle
Copyright ©2008 codeMantra LLC, All Rights Reserved
Final Edited Files
DE
PRINT
POD
IMAGE
ePub
ePub
ePub
Sony
Mobi
Kindle
DE
page
of content, has a much easier time rendering his content to all
possible formats – print, POD, PDF for the Web, ePUb, formats
for mobile phone, and web Services formats such as RSS.
XML Change Management A One to Many Relationship
By maintaining a single source of all content in XML, publishers
are able to leverage the structure inherent in the markup to better
manage edits, revisions and up-dates. When burst into content
fragments or chunks, book content can be properly configured to
take advantage of common and replicable elements. An element
common to multiple publications, will exist as a single instance
within the repository and any edit to that element can be passed
through to all publications that reference it.
For example, a series of travel books might all contain the
same chapter on travel insurance and currency exchange. When
market conditions force a re-write of this passage, a managing
editor is confronted with up-dating 9 individual publications.
For an editor relying on a basic flat file system (designated title
assets stored in 9 separate folders), the process will come down
to 9 copy and paste operations. But if the publisher has made
the transition to XML, the target chapter should be stored as a
stand-alone chapter referenced by each of 9 XML documents.
The managing editor needs only up-date the one file and changes
will be transferred across the entire array of titles.
Digital Editions and the Kindle derives ePub from the MobiPocket
reader which it has adapted. As one might expect, both devices
have their own idiosyncrasies (features) for which the ePub must be
configured. As all eReading systems and devices compete and evolve
(one could argue we are still in the bronze age of this development
path), there will undoubtedly be many more features and capabilities
requiring further adjustments to the ePub spec.
XML: Bringing a Competitive Edge
to The Publishing Process
A medical dictionary on a smart phone, reference works as online
databases, the eBook/audiobook hybrid (read or be read to), a
travel book tethered to the iPhone’s GPS application (see figure
4)2 … the delivery of content is without limits. There is no “for
sure” when it comes to predicting how consumers will choose to
access content five or ten years from now. But the wait-and-see
attitude has its opportunity costs.
Figure 4 - Modality, Inc.’s adaptation of a Frommer’s Travel Guide is
made more immediate with the GPS application within Apple’s iPhone.
ePub: An ebook Solution, but
Not an XML Solution
That ePub is referred to as an XML file is not inaccurate. But more
accurately, ePub is derived with XHTML, a hybrid of HTML and
XML. It is an extensible version of HTML. It is understandable why
the IDPF turned to XHTML as the standard markup language for
eBooks. XHTML is absolutely appropriate for rendering content
in browsers and most handheld devices. Essentially, XHTML is a
DTD (document type definition) for publishing simple documents
– most often from content that was originally published on the web.
The ePub spec was developed at the behest of publishers seeking a
standard format for eBooks – a format that all eReading systems and
devices would be forced to accept. Indeed, the major players (Sony
Reader, Amazon’s Kindle, Adobe Digital Editions and MobiPocket)
have adopted the ePub spec.
But XHTML doesn’t support the kind of semantic tagging
that is possible with XML. And while ePub will render to a Sony
Reader, using that same file as single source for print output or as
the feed for an XML application other than an eReading system is
not always possible. Adding to the impracticality of using ePub, as a
single source of XML, is the fact that the ‘standard’ is still evolving.
Neither the Sony Reader nor Amazon’s Kindle are able to use ePub in
its native form. The Sony Reader renders ePub files through Adobe
page
2 Courtesy of Modality, Inc. (www.modalitylearning.com)
All content © Wiley Publishing, Inc.
Copyright ©2008 codeMantra LLC, All Rights Reserved
Setting aside the author as a best-selling “brand”,
publishing, over the course of its history, has established some
highly recognizable brands –, for Dummies, Joy of Cooking,
7 Habits, Lonely Planet, Cliff’s Notes, Fodor’s, Kaplan, Chicken
Soup, Penguin Classics, Better Homes & Gardens, South Beach,
Old Farmer’s Almanac, Gray’s Anatomy, What to Expect When
You’re Expecting, Who Moved My Cheese, Left Behind, Brain
Quest, to name just a few. Publishers will argue that these brands
were the result of clever packaging and marketing – factors
that should not be dismissed. But one key contributor to the
success of these brands was distribution. At the height of the
mass market expansion, the dominant houses were capable of
distributing millions of paperback copies to tens of thousands of
outlets. A gripping package or marketing promise was face-out
in thousands of paperback racks in drug stores, grocery chains
and airport newsstands the world over.
That mass market exposure has transitioned to the web.
New packaging and messaging is called for, but more importantly
new content delivery is being asked for. Traditional publishers
are highly vulnerable to renegade content aggregators, capable of
pushing new forms of information and content with access to the
most direct and efficient distribution means ever.
A virtual Betty Crocker? Why not? The original Betty Crocker
was a virtual entity, created by the marketing department at General
Mills in the late ‘50s. Beyond cake mixes and food products, she
has sold tens of millions of books, pamphlets and subscription
services. But General Mills success and, subsequent to that, the
success of the various publishers of Betty Crocker cookbooks, was
years, and millions of marketing dollars, in the making.
Web 2.0 – the social networks and peer-to-peer exchanges on
today’s internet – make it easier than ever to create and establish
a brand. YouTube, FaceBook, MySpace, WebMD, even Google and
Yahoo, are brands that sprung up from relatively small investments
and grew quickly. Online sites such as CheapTickets, Travelocity,
Expedia and PriceLine established themselves in very quick order
and have put the Thomas Cooks and Carlson Wagonlits of this world
on the ropes. What’s to stop the Food Network from establishing
a unique cookbook application and brand? Blackboard offers an
enormous menu of on-line teaching applications; they could easily
become a competitor in the test prep market. Wikipedia may not
be as authoritative as Britannica, but today it is Britannica that has
to do the catching up.
The Instant Book – Back When…
The speed with which information now reaches the market far
eclipses the time it takes publishers to design and craft a book; print
it and distribute it. The print publishing process, at some of the
larger trade houses, has produced a small list of what the industry
calls “instant” books. These would be books covering a highly
contentious issue or political development – books that chronicle
a sensational event or commemorate an historic milestone. Under
the best of circumstances, the complete publishing cycle would
Copyright ©2008 codeMantra LLC, All Rights Reserved
still take a minimum of 14 days, not counting the meetings and
planning that went into green-lighting such a project. Fourteen
days is an entire business cycle on the web. Publishers can knock
days even a week out of this process with an instant eBook.
It’s not that the printed book is no longer able to compete.
There are still plenty of readers who appreciate the skill and
care that goes into a well –researched, well-written, well-edited
and well-packaged work of fiction or non-fiction. But once the
content has been refined and captured it should reside in a form
that can be quickly transformed to meet the alternative delivery
formats. Demand can materialize for all, or portions, of the
content in any number of markets and publishers should be in
a position to capitalize. By storing and managing a single source
of content in XML, publishers can move quickly to configure
their content to meet the requirements for whatever lucrative
digital format presents itself. Or, as was the case with the lobbyist
looking for the rights to a single chapter, a simple up-load of an
XML file completes the transaction.
An In-House Solution vs. an
Outsourced Solution
Managing a digital publishing program and the workflow it
requires is not without its challenges. Publishers must first decide
on how much of the process and infrastructure they wish to own.
For some, the decision is to boldly bring everything in house. Build
the Digital Asset Management system; manage the production
process and the distribution. Others want little or nothing to do
with digital formats and are quick to throw their content over
the wall to third party providers who manage it in exchange for a
percentage of the sale.
Somewhere between these two extremes is where a growing
number of publishers are seeking a solution. They want to retain
control over their content, but are not prepared to acquire the
infrastructure and human resources required to go it alone.
codeMantra has a solution for these publishers, called Collection
Point™. Through the combination of a server platform, software
and services, Collection Point provides the complete range of
digital production and digital warehousing capabilities. Publishers
are able to up-load content to codeMantra’s repository, where they
retain the same access and control as if the facility was their own.
Collection Point’s browser-based interface allows publishers to
manage all versions and formats of their title offerings. They can
order conversions, which codeMantra executes through its Chennai
production facility. codeMantra operates as an independent
distribution service, without ties to any retailer or wholesaler.
Content stored in Collection Point can be converted, packaged and
uploaded to any global wholesaler or retailer. The system provides
the exact same utility as that of an in-house digital warehouse, at
a fraction of the cost.
page
Publishers currently using Collection Point not only manage
and distribute their content to institutional libraries, public and
private libraries, eBook wholesalers and retailers, but also the
associated metadata. The system automatically ingests ONIX and
BISAC feeds and can be configured to handle almost any kind of
custom metadata feeds.
Architecting a practical digital publishing strategy should be
a publisher’s first goal. Publishers need to understand the long
term and short term implications concerning content conversion,
warehousing of data, rights management and distribution plans.
The staff at codeMantra consists of both veteran publishing
executives and experienced software engineers (in some cases
one and the same individual). The company provides excellent
consultation services in helping publishers devise an approach
that will deliver optimal flexibility with the lowest overhead. Once
decisions have been made, codeMantra software engineers build
the data models and write the scripts, applications, stylesheets and
APIs to deliver the digital publishing workflows tailored to the
publisher’s needs.
Further Reading
There are hundreds of books on XML and publishing content
management; here are three worth visiting:
1. XML For the World Wide Web, by Elizabeth Castro, Peachpit
Press © 2001 Elizabeth Castro and soon to be released XML
Visual Quick Start Guide 2nd Edition, By Elizabeth Castro
and Kevin Howard Goldberg, Peachpit Press
2. XML for Dummies® by Lucinda Dyke and Ed Tittel
copyright ©2004 by Wiley Publishing, Inc. (available in
Adobe Digital Editions)
3. Managing Enterprise Content , A Unified Content Strategy,
by Ann Rockley, New Riders (imprint of PeachPit) a division
of Pearson ©2003 Ann Rockley
page
Inquire Further of These
codeMantra Software Solutions
Collection Point
codeMantra provides a comprehensive digital asset management
system managed through a suite of web-based tools enabling
content owners to manage and distribute their digital assets.
The system is positioned on a fully supported data repository
to host all versions and formats of the assets, with user-friendly
and powerful tools available to authorized users, no matter their
location. These tools allow digital content to be repurposed into
new revenue streams, providing a complete archive solution at
the same time. The Collection Point™ system allows content
owners to focus on content, not the logistics of file storage and
delivery.
pubXML
In an ongoing effort to create efficiencies and solutions for
the digital content industry, codeMantra has taken its years
of experience in digitizing book and journal content and put
that knowledge into an XML solution and created a robust
and comprehensive XML format named PubXML. Part of this
extensive development process was to create a document type
definition (DTD) that would serve as a solid XML format for all
of the publishing and distribution community that codeMantra
serves. The end product of this process was the creation of a
robust and versatile XML system that supports codeMantra’s
internal conversion and data management solutions and can also
serve as an XML system for any content manager..
Universal PDF
The PDF file specifications of electronic distribution channels
are as numerous as they are varied; and have required content
owners to convert their content multiple times to ensure broad
delivery. The Universal PDFSM solution from codeMantra
allows content owners to have one fully-compliant file created
for 10 of the leading electronic content distributors, as well as
several additional electronic content aggregators, including
Google Book Search and Amazon’s Search Inside program.
Copyright ©2008 codeMantra LLC, All Rights Reserved