HTML5: Well, Maybe.

I just finished reading an article about Roger McNamee’s bold predictions about social media.  Aside from some the interesting business predictions (e.g., don’t invest in new social media startups: that train has left the station) that I mostly agree with, he is strongly emphasizing the emergence of HTML5 as the technology that will drive application development in the future.  On this point, I’m not ready to throw my FlexBuilder, Visual Studio, Eclipse and Android SDK development environments in the dust bin just yet.  Forget about scrapping my Notepad++ or Oxygen environments, these are keepers for the long, long term.

Yeah, HTML5 definitely has much promise:  Canvas alone is just cool.  I’ve seen some really interesting things done with this, and it can only get better from there.  Yet one cool enhancement for a browser isn’t enough to keep my attention long term, nor is it a game-changer that will revolutionize how users interact with application interfaces. 

So what kinds of things will keep me saying, “you had me at hello.”?   The big deal for me is looking at the world through the publishing industry’s collective eye:  Many of the big publishers are in the midst of what can considered a paradigmatic shift – while print will still be a prominent part of their business model, it won’t be the dominant model.  This is a significant change.  Publishers will transform themselves from content designers to media conduits. 

OK, so how what will HTML5 need to have to be compelling for publishers to adopt it?  I see three things, all of which are requirements for the browser vendors to reconcile:

1. Media Codec Standardization
2. Support other key technical standards (EPUB, MathML, etc.)
3. Form-factor scaling

Media Codec Standardization

Right now, there are myriad of audio and video standards like H.264, Ogg (Theora for audio; Vorbis for video), MP3, Speex, AAC, WAV, and so on and on and on.  The problem is that none of the current browsers support a common set of these, and even when they do support them, their support varies.  Until they figure that out, HTML5 will not be able to leverage its full capability and publishers will be reluctant to adopt it.

References:  http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5_Media);

Native Support for other Standards

OK, this one is a big, huge stretch and probably not going to happen anytime really soon.  Well, OK.  Ever. That said, these are the types of challenges that publishers have to face currently as well as going forward.  EPUB is the biggest stretch only because it leverages HTML (and ZIP compression) anyway, but the capability to embed EPUB in an HTML container would be a big win.  Yet for technical publishers, i.e., engineering, science and math publishers,  there hasn’t been a good solution for displaying all manner of math equations in browsers – they’ve had to rely on either transforming the equation to a raster image (and only recently to vector images like SVG) or rely on plugins to render the equation.  More recently, we’ve seen developments like MathJAX (http://mathjax.org) that rely on Javascript libraries to consume LaTeX scripts and display equations.  A bit better, but not quite as elegant as leveraging structural markup. 

The bottom line is that this requirement is probably more of a “nice to have,” but for STM publishers, its key to their business. 

Form Factor

This is probably the most significant limitation today.  It would be one thing if all applications/browsers were bound to desktops and laptops.  The reality is that mobile devices, all of which have different dimensions ranging from relatively small smart phones to now tablets means that application interfaces have added challenges to support these different form factors.  Today, I would be hard-pressed to recommend HTML5 UI libraries over native mobile OS UI controls. 

The Future

Will HTML5 become the preeminent technology platform? My magic 8-ball on my smart phone says “Ask again later…”  This resonates the same for me.  I’m hopeful that HTML5 can live up to the promise and can become the common technology platform for all applications.  But right now, there’s just too many holes in the various browser engines to make it practical.  Don’t expect browser vendors to patch these holes quickly.  In the meantime, several factors will impede HTML5 adoption:  Flash, warts and all, is still largely ubiquitous.  Its influence is slowly diminishing, but it won’t go away anytime soon.  In addition, Javascript libraries like JQuery, YUI and Dojo are maturing, but I think we’ll need to see how they shake out over time.  I’ll defer to Javascript experts to tell me which of these will become integral for HTML5 applications.

Lastly, HTML5 won’t be promoted to true standard status for another 10 – 11 years.  This is a lifetime, almost an epoch, for technology.  Lots can happen in that time.  It’s hard to predict right now what emerging technologies will come along that will impact content and media, but chances are something will.

Update (7/23/2011 05:08 PM MST):  Even more articles are coming out suggesting HTML5 will be a boom industry (see http://gigaom.com/2011/07/22/the-html5-boom-is-coming-fast/):  Could be real, but could be a bubble.  I’m not convinced yet that browsers are up to the task – yet.

IPRM != DRM

Over the last year, I've been developing strategies that allow publishers to define and identify IP Rights. The big difference between digital rights management (DRM), and IP rights management IPRM is that DRM is about locking down assets to mitigate against piracy. IPRM is about identifying and calculating clearance to use assets for any given context, and enabling publishers to make informed decisions about using specific assets.

ODRL, or Open Digital Rights Language, is a well-established, robust, extensible XML markup designed specifically for this purpose. At it's core is the ability to define relationships between parties, assets, and permissions (i.e., print, display, execute). But it's real power is the ability to express complex permissions that include conditions and constraints. For example, "a licensee can use an asset in a printed book, but the print run is limited to 2,000 copies, and the asset creator must be given proper attribution and will receive two copies of the book prior to its release", or "the asset can be used in print, except that it can't be distributed in North Korea".

This is powerful, and gives publishers the capability to monitor and evaluate rights clearance while the product is in development. Using an XML Database and XQuery, it's relatively trivial to calculate clearances for all assets for a product and to display the information in a dashboard. Editors can monitor the progress of rights clearances against all assets and determine whether to acquire additional rights to use assets that haven't been cleared, or to use other assets instead. Publishers can also track asset usage to ensure that the proper royalties are paid. It also helps publishers in "what if" scenarios: they can easily determine the cost and feasibility of adapting a product for a different market, which will tell them how many of the existing assets are cleared for use in that market and how many remain that either need additional clearance or should be replace with other assets.

Another scenario we're working on is using ODRL for wholly-owned assets. Publishers frequently commission third parties to produce photos, images, and other rich media for which the publisher retains the rights to. They want to reuse these assets for obvious cost savings, however, they don't want to over-expose assets. Frequently, editorial teams are primarily focused on one project or program, and have little insight as to what others are doing, so it's quite possible that an image could be used by more than one product at the same time. Not that this is always a bad thing, but it can lead to over-exposure. Using ODRL to manage access to assets, using embargo dates and other usage information, editorial groups can quickly make informed decisions whether to use an asset or look for another.

Pretty cool stuff

Using DITA for Genealogical Data

I’ve been working on putting my family history together for the last few years.  Most of the genealogical applications have some pretty nice features, but none seemed to have all of the features I wanted.  I wanted the ability to manage all of the summary information and relationships (all applications do this), but also cross reference the factual data with individual biographies.  And, I want to be able to display the information in different ways and formats – not just the ones supported by any particular application.

I started looking at the format that most genealogy programs store the data into.  With few exceptions, they all use GEDCOM, or GEnealogical Data COMmunication.  The standard was developed by the Church of Jesus Christ of Latter-day Saints as a means of creating a portable data format to express information about individuals, families and sources (bibliography).

GEDCOM is line-delimited field format that identifies the start of a new record with the number 0.  Fields within a record are identified with an incremented number.  For example a first level field line would start with the number 1.  A subfield (e.g, the given name of a person’s full name) would start with the next highest number. The following is an example record for an individual

  0 @1@ INDI
    1 NAME   Robert Eugene/Williams/
    1 SEX   M
    1 BIRT
      2 DATE   02 OCT 1822
      2 PLAC   Weston, Madison, Connecticut
      2 SOUR   @6@
        3 PAGE   Sec. 2, p. 45
        3 EVEN   BIRT 
          4 ROLE   CHIL
    1 DEAT
      2 DATE   14 APR 1905
      2 PLAC   Stamford, Fairfield, CT
    1 BURI
      2 PLAC   Spring Hill Cem., Stamford, CT
    1 RESI
      2 ADDR   73 North Ashley
        3 CONT   Spencer, Utah UT84991
      2 DATE   from 1900 to 1905
    1 FAMS   @4@
    1 FAMS   @9@

 

Other than the line/sequencing delimiters, the data structures are pretty free form, and is parser dependent.  Even the field names, outside the common set supplied by GEDCOM are parser dependent.  So if you use one genealogy tool, it can understand these fields, but if you try to load it in another, it blows up.  Gah!  Add to that, GEDCOM just isn’t that great for handling rich content like pictures in a biography.

This sounds like a job for XML. 

So the first question I had to address is how to model this.  I’ve looked at some the of GEDCOM XML sites, and they suffer from the same problems as the text data structure do.  Just not enough rich data. 

The answer I came up with was to use DITA, which has several things going for it:

1. I can easily mimic GEDCOM’s data structure with a specialized map
   
2. I can extend the model to support other potentially valuable metadata
   
3. I can easily model rich biographical content as a topic specialization
   
4. DITA’s numerous linking mechanisms work well for the various types of links I would need:  internal references within a map, rel-tables, cross-references, external hyperlinks to third-party websites and content.

The first thing I did was to model and create a map specialization that mimics the GEDCOM data.  For the sake of brevity, I’ll show a sample of a specialized map.  If you want more information, ping me:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE familytree SYSTEM "file:/opt/dita/1.2/dtd1.2/genealogy/dtd/familytree.dtd">
<familytree>
    <title>Schmoe Family Tree</title>

    <individual id="I1" keys="I000001" gender="male">
        <vitals>
            <personname>
                <firstname>Joseph</firstname>
                <firstname type="nickname">Joe</firstname>
                <middlename>Aloysius</middlename>
                <lastname>Schmoe</lastname>
                <generationidentifier>III</generationidentifier>
            </personname>
            <birth>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1968</year>
                </date>
                <location>
                    <placename>The Stork Factory</placename>
                    <addressdetails>
                        <locality>Anytown</locality>
                        <administrativearea>Anystate</administrativearea>
                        <country>USA</country>
                    </addressdetails>
                </location>
            </birth>
        </vitals>
    </individual>
    <individual id="I2" keys="I00002" gender="male">
        <vitals>
            <personname>
                <firstname>John</firstname>
                <firstname type="nickname">Jack</firstname>
                <middlename>Michael</middlename>
                <lastname>Schmoe</lastname>
            </personname>
            <birth>
                <date><day>1</day><month>1</month><year>1948</year></date>
            </birth>
        </vitals>
    </individual>
    <individual id="I000003" keys="I000003" gender="female">
        <vitals>
            <personname>
                <firstname>Jane</firstname>
                <middlename></middlename>
                <lastname type="maidenname">Doe</lastname>
                <lastname type="marriedname">Schmoe</lastname>
            </personname>
            <birth>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1947</year>
                </date>
            </birth>
        </vitals>
    </individual>
    
    <family id="f1" keys="F1">
        <familymeta>
            <marriage>
                <date>
                    <day>1</day>
                    <month>1</month>
                    <year>1967</year>
                    
                </date>
            </marriage>

        </familymeta>
        <child keyref="I000001"/>
    </family>
    <familyreltable>
        <record>
            <indi>
                <personref keyref="I00001"/>
            </indi>
            <famc>
                <familyref keyref="F1"/>
            </famc>
            <fams/>
        </record>
        <record>
            <indi>
                <personref keyref="I00002"/>
            </indi>
            <famc/>
            <fams>
                <familyref keyref="F1"/>
            </fams>
        </record>
        <record>
            <indi><personref keyref="I00003"/></indi>
            <famc></famc>
            <fams>
                <familyref keyref="F1"/>
            </fams>
        </record>
        
    </familyreltable>
</familytree>

The Butterfly Effect of Oracle’s Lawsuit Against Google

No one knows with any degree of certainty what the outcome will be from Oracle’s patent infringement lawsuit against Google.  While the impetus of the lawsuit is largely focused on Dalvik, Google’s mobile VM based on Java, the consequences of legal action will likely reverberate through the larger Java world. 

I don’t have a dog in this fight.  Yet. On the one hand, Oracle appears to be hell bent on reversing Sun’s decision to release Java to the open source community, according to an InfoWorld article:

It's no secret that Larry Ellison wants to make money from Java, something Sun's execs, whom Ellison held in contempt, was never able to do. It may be that Oracle wants nothing more than a cut of Google's Android revenue -- IDC's Will Stofega told Bloomberg News that the case will probably end with Google agreeing to pay to license Oracle's patents.

On the flip side, it sure looks like Google didn't do any favors for itself either. 

Whatever the case, there are potential far reaching implications of Java in the open source world.  For one, it will reinvigorate the debate around software patents. More specific to my interests here, XML was, and is, heavily influenced by Java and open source. Think Xerces and Xalan, Saxon, FOP, Ant, and more recently Calabash and Calumet.  It also factors in to related technologies like the APIs  for eXist and MarkLogic, and fuels reference implementations of standards like DITA (see the DITA Open Toolkit).

My immediate reaction is the cat’s already out of the bag: Java is already open source, which means nothing will change for XML technologies.  For now.  In the short term, it’s very likely the only ones affected are Android application developers.  Longer term, however, Oracle’s behavior might well impact a wide array of technologies, including XML, by deterring developers from using Java in the first place.  That would be a huge detriment to XML across many technologies and industries.  Let’s hope it doesn’t get to that point.

Technorati Tags: XML,Oracle,Open Source

Cancer Sucks

My Grandparents died from it. My mother had it (in remission), but now she needs to have a full mastectomy because a genetic marker indicates she's at higher risk to get it again (she has surgery on March 7). And now, a friend and colleague of mine has it. This guy is healthier than 95% of other men his age, has like zero body fat, and is always encouraging everyone to ride with him (more like follow from a long distance). That's just hard to take in and process. While he's the one that has his world rocked, cancer also has a nasty side effect on family and friends. Put it bluntly: Cancer sucks.

Few other spoken words, irregardless of language or dialect, can evoke as much emotion as 'cancer'. Even as scary as influenza and other diseases like AIDS are, and as much devastation they can bring to an individual, a family, a community, and even the world, there's something about cancer that is so viscerally scary to us. For me it's because cancer is, in my non-medical, simpleton view, a mutation of cells. It's not like a virus or an infection where a foreign organism is making you sick, and you can take medication to kill off the nasty invaders - it's your own cells that, for some reason have started going haywire. That's just downright frightening to me. And that cancer is so seemingly random and unpredictable just makes that much more hard to take - you could be in the best possible physical shape and still get it.

Science and medicine have come so far when it comes to curing many forms of cancer. Many people have a good chance of living long, healthy lives if they catch the disease early. But often they have to go down through the depths of hell physically and emotionally to get to the finish line: cancer-free. Yet, they keep their eyes on the prize.

I'm pretty sure my friend will beat this. His odds are really high, and his outlook on life and his current illness are positive, which also increases his chances.

If nothing else, it's a reminder that life is too short, so live it to its fullest. It's so easy to become burdened with frustration, stress, angst, even hatred. In other words, we lose sight of the forest within the trees. I'm probably the most susceptible to this.

In short: Work hard. Play harder. Laugh more. Celebrate with your family and friends. Find something everyday that is good. A sunrise or sunset, a laugh with your kids, a hug or a kiss with your spouse or significant other, a walk in the park with your dog. It's your life - own it.

Apple to Release Tablet PC Today: e-Books are One Target Market

Apple is releasing their tablet PC today.  According to NPR, they plan to include an e-reader.  As I mentioned in a previous post, I though that the tablet was the perfect medium for e-books, and would supplant the Kindle, Nook and other current e-book devices.  Only time will tell for sure.

The move by Apple is brilliant.  It already has a first class distribution model with iTunes pushing out applications and music for the iPhone and iPod.  e-Books are just a natural progression. 

From an XML publishing standpoint, EPUB is a relatively easy format to render. The DocBook XSLT stylesheets has an EPUB format built in.  I'm not aware of one for DITA yet, but I can't imagine that it would be too far behind, or difficult to build.

Tablet PCs - What does this mean for e-Readers?

HP previewed their new tablet PC at the 2010 Consumer Electronics Show.  Apple will release their version later this spring.  Sounds to me like this could supplant the Kindle, Nook and other e-Reader devices.  It might also be the impetus for EPUB distribution.  e-Readers are nice, but they're one trick ponies. 

From an education publishing perspective, this could really open the door to new revenue models for schools at all levels to distribute published content.  It also opens the door for new models for authors writing content. 

More on these ideas later.