Content Delivery Decisions for Technology Strategists

Joseph BachanaPresident/Founder, DPCI

Leonor CiarlonePrincipal, LMC Communications

Peter O'KellyPrincipal Analyst, O'Kelly Associates

Thursday, November 29, 201211:40 – 12:40

2

Overall Session Agenda

• Not Dead Yet: The Significant and Sustainable Synergy of XML and SQL

• Convergence of Content Technologies in the Open Source World

• Q&A

3

Agenda: Not Dead Yet

• Synopsis• Complementary concerns– Resources– Relations– Apps– Admin/ops

• Perspectives and reality checks• Recommendations

4

Synopsis: Not Dead Yet

• XML and SQL are, respectively, the global standards for working with document- and Web-oriented information and traditional database management systems (DBMSs)

• However, both are also at least ostensibly under siege, with, e.g., – Some application developers shifting their focus to

JavaScript (and JSON, the JavaScript Object Notation)– Many software product marketing people and investors

touting the professed power of "NoSQL" (and “NewSQL”) systems

5

Synopsis: Not Dead Yet

• The stakes are strategic, with ever-expanding compliance and competitive considerations, and with compelling new opportunities based on– Big data– Cloud services– HTML5 clients– Mobile devices

• [Spoiler alert: neither XML nor SQL is going away]

6

Agenda: Not Dead Yet

• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations

7

Resources and Relations

• A digital information item dichotomy – Resources (~unstructured information): “content”

• Digital artifacts optimized to convey stories– Organized in terms of narrative, hierarchy, and sequence

• Examples: books, magazines, documents (e.g., PDF, Word), Web pages, XBRL documents, video, hypertext…

– Relations (~structured information): “data”• Application-independent descriptions of real-world things

and relationships• Examples: business domain databases (e.g., customer,

sales, HR…), data.com, wikidata.org…

8

A Big-Picture Framework

Resource RelationW

ord

docs

DITA

doc

s

XBRL

doc

s

PDF d

ocs

Oper

ation

al d

b

Desk

top

db

9

Separation of Concerns

• Back to basics– XML (with namespaces, XSD, XPath, XQuery, XSLT, …) for resources

• Presentation• Structure• Behavior

– SQL for relations• Application/data independence• Logical/physical data independence

• Related services for both information domains: identity, authentication, authorization, logging, transactions, indexing, dynamic storage optimization…– Ideally handled by underlying information management systems

rather than applications

10

Complementary Concerns

Apps

Relation

Admin/Ops

Resource

11

Agenda: Not Dead Yet

• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations

12

Resource Perspectives

Apps

Relation

Admin/Ops

Resource

• Every useful thing is a resource (document/page)• SQL is for uncreative and obsessive data nerds• Apps are interactive/compound resources• Admin/ops: somebody else’s problem

13

Relation Perspectives

Apps

Admin/Ops

Resource

Relation

• Relations can describe all useful things• Resource: XML compound data type instance• Apps are interfaces for relation interaction• Admin/ops: somebody else’s problem

14

Application Perspectives

Apps

Relation

Admin/Ops

Resource

• Anything that’s not an app is just for archival• Resource => XML => verbose/unwieldy• Relation => SQL => impedance mismatch• Admin/ops: somebody else’s problem

15

Admin/Ops PerspectivesApps

RelationResource

Admin/Ops

• Robust/scalable admin/ops or we all go to jail• Resource => XML => eXtra Mondo Large files• Relation => SQL => a DBMS trying to be an OS• Apps: most likely to break infrastructure

16

Vendor Marketing Perspectives

• Resources: a Web-centric approach fixes everything

• Relations: NoSQL fixes everything

• Apps: JSON fixes everything• Admin/ops: the cloud fixes

everything

17

A Reality Check

“Everything should be made as simple as possible, but no simpler.”

18

Modeling AbstractionsResources Relations

Conceptual Documents and links; documents focused primarily on narrative,

hierarchy, and sequence

Entities, attributes, relationships, and identifiers

Logical Model: hypertextLanguage: XQuery (ideally…)

Model: extended relationalLanguage: SQL

Physical Indexing (e.g., scalar data types, XML, and full-text), locking and isolation levels (for transactions), federation, replication/synchronization, in-memory

databases, columnar storage, table spaces, caching, and more

19

A Resource Reality Check

• XML has some idiosyncrasies, but it’s beyond good-enough for its primary target domain, and it’s here to stay– Indeed, XML is, in some respects, just getting started

• XQuery, in particular, is exceptionally powerful

• But XML should be made invisible to information architects, application developers, and admin/ops– They should work with tools that support their

respective levels of abstraction, but that still leverage XML when appropriate

20

“A DBMS is good for my XML?”

21

A Relation Reality Check

• SQL has some idiosyncrasies, but it’s beyond good-enough for its primary target domain, and it’s here to stay– Being anti-SQL, ultimately, is being anti-set theory

• Not a good bet when you’re describing sets of things

• But SQL should be made invisible to information architects, application developers, and admin/ops– They should work with tools that support their

respective levels of abstraction, but that still leverage SQL when appropriate

22

XML and SQL

• XML and SQL are sustainably complementary– When used appropriately

• XQuery was designed – by a team including one of SQL’s creators – to complement SQL

• The market-leading RDBMSs can automatically ingest and generate XML

• Some leading XML servers are adding SQL support

23

An App Perspective Reality Check

• The dreaded “impedance mismatch” is mostly a consequence of inadequate programming languages and tools

• Reverting to a programs-have-files perspective means ignoring decades of software engineering evolution

• Using JavaScript doesn’t have to preclude the effective use of XML and SQL– But tools that don’t entail major compromises are only

now starting to appear

24

An Admin/Ops Reality Check

• DBMS evolution isn’t done yet– Multi-model DBMSs are now the enterprise norm• Including subsystems for XML, file steaming, spatial

data, and more

– Automatic “sharding”• New extensions to logical/physical database

independence and database optimization

– A leading indicator: watch what Google does with SQL (or “SQL-like” approaches) in BigQuery and Spanner

25

Agenda: Not Dead Yet

• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations

26

Recommendations

• Build consensus and establish clear criteria for what to use when (and how)– Otherwise people will often default to the tools

and technologies with which they’re most familiar• And/or the most fun or résumé-enhancing

– Best practices start with effective modeling and query formulation skills• Reminder: XML and SQL should be invisible to most of

the people who benefit from using them

27

Recommendations

• Only invest in tools that don’t dumb-down XML or SQL DBMS usage patterns– RDBMS and XDBMS are exceptionally powerful• But not when they’re demoted to serve as basic file

systems

– Many advocates of “NoSQL/NewSQL” systems have large collections of simplifying assumptions• Sometimes going beyond “… as simple as possible”

– With major compromises and trade-offs that are sometimes not fully understood until far into a project lifecycle

28

Recommendations

• Start preparing now to fully leverage advances such as – Pervasive beyond-the-basics hypertext– Multi-model DBMSs that apply XML/SQL synergy• Especially high-performance XQuery/SQL integration

– Don’t discount the possibility that the DBMS “usual suspects” (commercial and open source) will eventually provide the most effective XML + SQL products/services

29

Recap: Not Dead Yet

• XML and SQL are – and will continue to be – respectively, the global standards for working with document- and Web-oriented information and traditional DBMSs– Although they will ideally be invisible to most people

• Many of the alleged successors to XML- and SQL-related technologies are more complementary than competitive– JavaScript tools can productively coexist with XQuery and SQL,

for example– Most “NoSQL” and “NewSQL” developments are primarily

focused on the physical database layer, and aren’t in conflict with evolving XML and SQL DBMSs

30

Recap: Not Dead Yet

• The stakes are strategic, with ever-expanding compliance and competitive considerations, and with compelling new opportunities – Which are likely to accelerate rather than derail

XML and SQL market momentum• This is an opportune time to build consensus

on and skills in related techniques and tools

31

Q&A