Inside Analysis

Data Interchange Flexibility

The Knowledge Sharing Push

We are now seeing a global push towards knowledge sharing. This effort is prompted by many factors such as fostering innovation, getting product to market quicker, and improving organizational efficiency.

It would seem logical to apply something in the order of quantum mechanics to help solve the knowledge sharing conundrum. While quantum mechanics can help to explain the motion and interaction of atoms and subatomic particles, the same cannot be said for knowledge sharing solutions because of the human factor (unpredictability).

In theory a knowledge sharing structure should tap all of the information held within an organization to form a cohesive knowledge sharing framework. However, not everyone in an organization is willing to “give-up” their expertise to others because as the old saying goes: “Knowledge is Power and Power is Knowledge.” As a result, fiefdoms are often created and “only enough” information is given when asked. Thus, we should use the term Selective Knowledge Sharing (SKS) because it seem to be closer to the mark. It also stands to reason that the more transparent the knowledge sharing framework, the greater the chances of reaching organizational goals and objectives.

The Dilemma – What Standard or Standards to Support

The key question “what standard or standards should we support as an organization?” is a challenge that many CIO/CTOs currently face on both the domestic and international fronts. Case in point: When deploying a wireless trading application in Hong Kong for a large North American bank many internal and well as external issues arose. Not only was the ability to support Mandarin and Cantonese a primary concern, but also how to deal with data exchange with local carriers. This complex deployment exposed the various challenges of not only dealing with internal (North America to Asia) data exchange, but also interfacing with local business partners. Consequently, this dilemma is one many organizations currently face – which data interchange standard or standards to support.

The Possible Options

As the experts in this study have exposed, JSON and XML offer a multitude of benefits, so supporting both could ultimately allow for greater flexibility across the global data stage. Not to be forgotten is the vision of the Semantic Web and model for data interchange – Resource Description Framework (RDF). It seems that the market is still somewhat immature, so organizations need to be highly flexible and closely investigate which option or options best meets their short-, medium-, and long-term goals and objectives. As this point in time the debate seems to revolve around JSON and XML regarding which is best for internal and external facing knowledge sharing applications. Below are the two prime areas of interest:

Internal Facing Systems – What do we have currently in place for internal data interchange?

External Facing Systems – What data interchange structure is currently in place to deal with our business partners, and what technologies are they building to?

Technology Snapshot

JSONJavaScript Object Notation is an open-standard format that uses human-readable text to transmit data objects consisting of attribute value pairs. It is built on two structures:

1)     A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

2)     An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

XMLExtensible Markup Language is a non-proprietary subset of SGML. It is focused on data structure and uses tags to specify the content of the data elements in a document, while XML schemas are used to define and document XML applications. Web services are components that reside on the Internet and have been designed to be published, discovered and invoked dynamically across various platforms and unlike networks. The methods, which reside in a specific Web service, may use Simple Object Access Protocol (SOAP) to send or receive XML data. Thus, XML eliminates laborious steps involved with creating a remote object. An example of traditional (centralized application development) and Web services (distributed network-centric applications based on XML) models includes CORBA, which requires that the methods written in the language supporting CORBA be converted to interface definition language (IDL) before being used. Another example is calling methods without using the IDL because a programming language needs only be able to make a call across the Internet using HTTP and then handle an XML response.
RDFResource Description Framework is metadata model for describing objects and the relationships among them. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed. It extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a “triple”). Using this simplistic model, it allows structured and semi-structured data to be mixed, exposed, and shared across different applications. This linking structure forms a directed, labeled graph, where the edges represent the named link between two resources, represented by the graph nodes.


Views from the Experts

The primary goal of this study is to expose both the positives and negatives of each open-standard. Accordingly, below are different views from various well-respected experts:

JSON seems to be getting a lot of developer attention, yet as a longtime supporter of XML in standards, I think we need to be aware of it and remain flexible. It may be in our interest to consider providing JSON or JSON-LD (Linked Data) versions of standards originally specified as XML schema to make it easier for developers to implement these standards. Standards are only valuable if they are implemented. Likewise, we need to consider the usefulness of RDF representations, which can be mapped from JSON-LD, enhancing the value of an original XML schema-based standard.
~Rex Brooks, CEO-President at Starbourne Communication

Bottom line IMHO is that JSON trumps XML because of its flexibility and inherent ability to “be” unstructured, which I’m finding more and more important these days with the way people want to collect, assemble and consume data (particularly big data). While you can allow XML to deal with unstructured data, if you rely on your schemas (as you should if you’re using XML) you’ll be forced to continually update your schema. Then there’s SOAP for data transfer and the multitude of XML parsers to deal with. For JSON, it’s schema-less, but not un-schema-able. You can provide a schema, if you want to, with every object.  In this sense, it is self-schema-able.
~Charles Assaf, Software Architect

One would think that a mark-up copy operation is straight forward. For XML models with an inner “Core” (<StrategicPlanCore>) like StratML – there is only one copy operation view.

Not so for HTML where, thanks to Web Browser rendering, HTML behaves like a Central Processing Unit, recalculating ordered list display indices automatically according to the OL:Type Attribute.

Imagining that both you and a Cloud dweller both have access to a Browser, the same HTML page ought to produce identical indices for identical ordered list types. Of course other style features can vary widely. While this muddies the pattern recognition waters somewhat, it should not have any persistent (e.g. non-reversible) effect on the data no matter how far apart the Browser Screens or Browser brand (any Browser using the same Industry Standards).

XML 1) a list of ingredient names and 2) fractional composition (=100%).
JSON 1) a list of ingredient names.
~Gannon Dick, Software Developer

JSON and XML are two complementary standards, each suited to different situations. JSON’s popularity is in no small part owing to the fact that it is built into JavaScript. That is JavaScript can read JSON directly without any additional parsing. This is a huge convenience for JavaScript developers. Given that it is also less verbose than XML, it is the often logical choice for sending transient data between the client and server layers within many web applications.

Whilst being more verbose, XML offers many other advantages. For example, XML schemas allow one to describe, extend, communicate and validate XML datasets. XSLT allows for easy transformation of XML from one format into another, and XPath/XFormat engines allow for deep querying of native XML files. It is this added maturity which makes XML better for communicating (and storing) data between applications.

Of course, with a little clever programming, or a handful of increasingly available third party tools, either standard can be used in most circumstances, leaving us spoiled for choice. Given the increasing prevalence of open architectures and cloud based software and data ecosystems, it seems likely that organizations will have little choice but to embrace both.
~Chris Fox, Founder & CEO:

All too often, questions are artificially couched in terms of either/or when both/and might be a better answer. The simple fact that many developers favor JSON is a good enough reason for them to use it to demonstrate to others what can be done with it. However, business-quality records require sufficient structure to support the purposes for which they exist. The appropriate tools should be appropriately applied for the appropriate purposes. 

Data without context is meaningless and, worse, can be easily misused for nefarious purposes. Now that a schema specification is being developed for JSON, perhaps it may become a worthy competitor to XML for business-quality records. That’s a matter of maturity, in the sense of the Capability Maturity Model (CMM). 

The business requirements should dictate the technology. Over time, as business managers come to better understand the technology, the business requirements will prevail. The question is how long it will take. In the meantime, any machine-readable rendition of information can be transformed into any other with relatively little difficulty – as long as both the semantic as well as the structure of the data are clearly specified.
~Owen Ambur, Chair StratML Committee

The debate between JSON and XML is generally overstated for a wide variety of use-cases. In most situations, which simply involve passing data around, it doesn’t matter which format we use. The best choice is far more a function of what application is designed, what the comfort level is of the developer, and preexisting systems in place. JSON has the perception of being lighter-weight with quicker response times, but the reality is that it in many real-world scenarios, XML might function as quickly anyway.

That said, when it comes to rich data that is actively parsed, transformed, or reshaped, XML is the go-to standard. XML is a full-featured language, which has its own rich set of features, standards, and applications framed around it, useful for querying, transformation, validation and more. The ecosystem around XML is not just focused on passing data back-and-forth in a lightweight manner, but on extending the data into new territories for maximum and even creative data utilization.
~Umesh Thota, Founder of & Ranjeeth Thunga, Founder of


Ironically, the goal of this short study was not meant to show which open-standard is best, but to take the debate to a higher level. As the experts from around the world have exposed, there are many important factors (e.g., deploying, communicating, storing, etc.) that should be taken into consideration. Regarding data interchange, open-standards that include JSON, XML, and RDF, all have a number of positive attributes along with various limitations. For those reasons, organizations should be both flexible and creative in deploying the next generation of knowledge sharing solutions.

It may seem rudimentary, but the larger the organization, the more fiefdoms seem to exist. As a result overlap often occurs, which means that resources are not being utilized in the most efficient way possible. This all too common scenario also raises the key question: Do we as an organization support too many technologies in our current portfolio, and should we consider supporting another open-standard?

Organizations should implement well-thought-out strategic plans and knowledge sharing frameworks that leverage open-standards (e.g., JSON, XML, RDF, etc.). This type of progressive and rational thinking will help to usher in the new era, one which promotes a more agnostic and human-centric World-Wide Web.

Russell Ruggiero

About Russell Ruggiero

Russell Ruggiero is Research Analyst focusing on Open-Standards.

Russell Ruggiero

About Russell Ruggiero

Russell Ruggiero is Research Analyst focusing on Open-Standards.

19 Responses to "Data Interchange Flexibility"

  • Gannon (J.) Dick
    September 12, 2016 - 2:41 pm Reply

    Kid: Mom, I want to be a quantum Physicist when I grow up !
    Mom: You have to decide; it’s either one or the other.
    The point for me being … are we being asked to share what we know or what think ? Or the third option, normally an external imperative, what; if metered to subscribers has sustainable commercial value ?

    Americans have a love-hate relationship with Identification Numbers for historical reasons – very good historical reasons – and so are prone to mistaking familiarity for semantics.

    This is a built in taxonomy of sustainable commercial value we all see at a young age. We grow up and the taxonomy mutates at glacial speed. Commercial sustainability hinges on “the numbers game” – how fast one can capture across the set.

    People: Social Security Number (etc.) : 123-45-6789 (9 digits, two hyphens)
    Places : ZIP Code : 12345-6789 (9 digits, one hyphen)
    Organizations : EIN (IRS, etc.) : 123456789 (9 digits, no hyphens)

    In principle, like the identification numbers, XML, JSON, or RDF are isomorphic. Any kid can grow up to be a quantum Physicist 🙂

    • Russell Ruggiero
      Russell Ruggiero
      September 13, 2016 - 9:52 am Reply


      As you point out, so many options.

      We have a created a information ecosystem that has to deal with structured and unstructured data. People are quick to point out that “Cloud Computing” is the answer, but that is not the case. A datacenter is a datacenter is a datacenter. What needs to be done is the following:

      Reengineering – Software and hardware reengineering is needed to make the applications better able to deal with structured and unstructured date. Not only is speed the issue, but first and foremost security. As we have seen over the last few years many breaches in the public and private sectors.

      Standards – What open-standards are used for data interchange is a key question most organizations must deal with from an internal, as well as external facing question.

      How we deal with this “new data-centric environment” today will have serious repercussions in the future if not handled properly. Hence, a reality-check is needed in the datacenter and what standards to use.


  • Michael Taylor
    September 12, 2016 - 6:21 pm Reply

    To Gannon’s point about the nature of what we are being asked to share, consider the following. We have asked over 200 business groups involved in corporate initiatives ranging from 4 to 2000 leaders and staff, ‘Why does your organization need to take action on this topic?’ and other ‘current state’ assumptions. We found that on average a group would express 40 separate, relevant opinions.

    On average, they would be aligned (all agreeing) on only 7 of the 40, and misaligned (some agreeing, some disagreeing) on 33 of the 40 opinions they and their colleagues expressed.

    After selecting the fundamental misalignments and reconciling them, the number will typically rise from 7 to 23 ‘It is…’, They are…’, ‘We have…’ opinions they all endorse as accurate.

    i.e. If we were to share what people think without knowing its validity, even when the source is a corporate CxO, there could be even more misinformation moving around as rational and logical but inaccurate fact. If we shared it after alignment analysis and reconciliation, perhaps we could have more faith in its accuracy.

    • Gannon (J) Dick
      September 13, 2016 - 1:12 pm Reply

      “If we shared it after alignment analysis and reconciliation, perhaps we could have more faith in its accuracy.”

      I could not possibly agree more and with fixed width Identifiers, alignment of the data base+query can and should be aligned for “first use” to fit the common sense definition of sharing. This means the data is “fresh out of the package” and that processing cost is what it is – in this case a *nix ZCAT command to the bit bucket (/dev/null).

      The JRC-Names data base from the EU Commission is an excellent benchmarking test bed for these issues. The technical word is for peer-to-peer trade/sharing is “Cabotage”. A Data Analyst might think of it as a game – “Share a Tag”

      It contains both Organizations and Persons all keyed to a big integer and has about 650,000 entries in multi-lingual scripts. There is a wide variance in subscription rates between branded organizations and named persons, but “buzz” can easily be annualized/normalized to 1 per month.

      Thanks for the reply.

      • Russell Ruggiero
        Russell Ruggiero
        September 13, 2016 - 4:50 pm Reply


        Thank you for exposing “The JRC-Names data base from the EU Commission is an excellent benchmarking test bed for these issues.”

        Here is a thing many people have trouble with “World-Wide Web”

        Yes, we need to have a true global perspective when talking standards.

        That is why we tapped the knowledge of experts across the world for the study, and this too is only a sliver of what is really happening.


    • Russell Ruggiero
      Russell Ruggiero
      September 13, 2016 - 1:30 pm Reply


      What you are exposing is the “alignment” issue. Now here is the hard part – Getting organizations to acknowledge that they have problem. Below is a photography analogy.

      Problem: Picture Out of Focus

      Does the photographer take responsibility or they blame the equipment? Let us say that diopters in the camera body only cover a certain range, but the photographer’s eyesight is in need of stronger adjustment to view the subject properly. The solution could be a stronger diopter attached to the eyepiece, or possibly a new prescription for their eyewear. In any event, things need to be acknowledged and addressed.

      What you are exposing is a whole new area that organizations need to probe deeper into. How do we get our internal ecosystem as well as external facing ecosystems onto the same page?

      It is here where your AOT solution provides the greatest value.


  • Dan Strongin
    September 13, 2016 - 11:59 am Reply

    Great example Michael, and therein lies the rub. A team is not a team without a shared objective. A system is a chaos generator unless it shares an objective. Those differing ideas lead to losses, serious hidden losses up and down the supply chain and in society overall. In my experience, those losses are the difference between no profit, profit, industry benchmark profit and oh my god, no one will believe me profit. If we are not conscious, if our systems do not bring things into the light of day, we are left with dumb luck, wasted resources, burnout and other unnecessary sindromes all to common because people do not sit down and really communicate on the things that are important. We are seeing companies go from top down do it or else to something more democratic, and that is good. But chaos is never good if you want to make money.

    • Russell Ruggiero
      Russell Ruggiero
      September 13, 2016 - 4:42 pm Reply



      Shared Goals & Objectives – Are the tread that should run through the organization. Wasted resources? In IT we see the old Define – Design – Develop – Deploy methodology, but in-between these “Steps” there is always a disconnect. Diving deeper, we see that a divide seems to always to exist between the Business and Technology. This most often leads to failed projects. The lucky ones that do survive are behind schedule, lack the requirements outlined in the Design Stage and, or are over budget.

      Alignment need to be “united” at all levels of the organization to promote a more cohesive environment.

      As you say, from the Greek “chaos” is never good.


    • Matthew Harang
      September 13, 2016 - 6:51 pm Reply

      Dan, I couldn’t agree with you more, and shared objectives cannot be achieved without efficient and regular communication. Communication must be free flowing and easy. There should be different types: formal, informal, written, verbal, visual, all used at the correct time and place to foster teamwork and ensure that the shared objectives are being met. Without communication, improvement, growth and innovation within team environments are all much harder to come by. The importance of leaders fostering such communication and leading by example cannot be overstated.

      • Russell Ruggiero
        Russell Ruggiero
        September 13, 2016 - 9:55 pm Reply


        Communication is what it is all about.

        Unfortunately, in the real-world we have to deal with personalities. As you know it means various data dikes and dams that impede information flow.

        Agreed, there should be different types: formal, informal, written, verbal, visual, all used at the correct time and place to foster teamwork and ensure that the shared objectives are being met.

        However, we humans are a strange lot and history has proven, also quite predictable.

        The work we are involved in is trying to breakdown communication barriers, but easier said than done. The most difficult task is not only exposing the problem, but having others realize that a problem does in fact exist.


        • Chris Fox
          September 14, 2016 - 12:54 am Reply

          The internet has been both a boon and a curse. It is a boon in that we now have almost instantaneous access to more information than we could have ever imagined, and can communicate with almost anyone on the planet in almost real-time. It is a curse because that volume and flow of information is like a firehose, overwhelming and blowing us away. How can we develop and pursue shared goals when we can barely stay on our feet in the face of this flow? Standards for semantic tagging of content (such as StratML) help us find structure and meaning in all of that content. This will become more so as tools develop which understand those semantic tags and can help people, identify, link and process that information more quickly. I remember being taught: write once, read many times. Unfortunately, as authors, we still take the easy way out when writing and don’t invest in adding the structure and semantic tags which make this possible. This is what desperately needs to change.

          • Russell Ruggiero
            Russell Ruggiero
            September 14, 2016 - 10:23 am


            Agreed, a boon and a curse.

            I took part in a nine part series on human behavior regarding digital devices. Some of the finding were quite troubling. For example, in Bryant Park in Manhattan some people just sat for hours looking at their smartphones and tablets without taking the time to enjoy the beautiful Fall afternoon. On another study, people dining outside on a Summer evening were texting on their devices throughout the entire meal, except when flagging the water down for drinks. Digital addiction?

            Regarding structure, you are absolutely correct, we must change the way we do things.

            “This will become more so as tools develop which understand those semantic tags and can help people, identify, link and process that information more quickly. I remember being taught: write once, read many times.”

            Think we have to make our standards more robust in the way they handle data, which means adding new features and capabilities to the framework to help promote our vision of Semantic Web.


  • Owen Ambur
    September 13, 2016 - 8:13 pm Reply

    I’ve been aware of Csikszentmihali’s conceptualization of “flow” for many years. Indeed, I experience it frequently when converting plans to StratML format. However, I’m finally getting around to reading his book on the psychology of optimal experience.

    As time permits, I’d like to document how many of his points relate to the StratML standard. However, the establishment of clear goals is among the eight major components of enjoyment that he identified.

    So the vision of the StratML standard might appropriately be restated as “a worldwide *flow* of intentions, stakeholders, and results” … in which experience is optimized for hundreds of millions of people around the world who take control of their own lives in partnership with others who share their objectives.

      • Russell Ruggiero
        Russell Ruggiero
        September 14, 2016 - 11:16 am Reply


        StratML (ISO 17469-1) is an interesting emerging open-standard.

        Where value is seen is in its alignment features. While the idealism of “aligning interested parties with the same goals and interests” is commendable, the ability for rubber meeting the road is where the public & private sectors may draw interest.

        Open, machine-readable looks to be the foundation we need to get to the goal.

        Strategic Planning – Performance Planning – Contingency Planning

        Let’s say we get hit with another Sandy category storm in NYC in the near future. Not only can StratML be of value with a Federal Agency like DHS/FEMA, but it can also work with state and local entities to respond in a more seamless and efficient manner. It can also enable private organizations better deal with disruptions with internal ecosystems and external facing systems because of defined framework that leverages open, machine-readable standards.

        Framework? Yes, a framework that starts with a Strategic Plan and runs a common thread throughout the entire organization to form a cohesive knowledge sharing ecosystem.


      • Michael Taylor
        September 15, 2016 - 1:11 pm Reply

        Regarding StratML, one strong reason why an organization should want to use StratML is that we have currently identified and templated over 50 ‘strategies’ present inside a business. Of course, we can all imagine the corporate strategy, then the business unit strategies, the departmental strategies, et al, but then there is the M&A strategy, the sustainability strategy, the diversity strategy, the go-to-market strategy, the IT strategy, the talent strategy, the supply chain strategy, and many more. Imagine if each of these were rendered in StratML – what it would do for clarity and alignment around them, and the ability to check integrity up/down and across them.

        • Russell Ruggiero
          Russell Ruggiero
          September 15, 2016 - 9:38 pm Reply


          Circling back, we look at knowledge sharing in its present form as fragmented at best and disunited at worst.

          Standards like XML, JSON, and RDF are just the means to get data from Point A to Point B.

          There in lies the problem is within organizations. It is the disconnect from senior management on down. Who gets what seems to be the main question. In theory if we create a well-thought-out Knowledge Sharing Framework than things should go as planned. Unfortunately we have a wildcard – Human Behavior. We as humans harbor behavioral traits that include narcissism and paranoia that inhibits knowledge sharing frameworks from reaching their true potential.

          Bottom line, it is not the technologies that limit knowledge sharing, it is human behavior.


        • Gannon (J.) Dick
          September 16, 2016 - 4:11 pm Reply

          Fifty is a very impressive number longitudinally speaking. Thanks for that.

          That was my real point about the JRC-Names Data Base above …
          It quickly becomes apparent that the search for additional variants (of names) is not a professional population analysis tool and at worst makes communication between knowledgeable peers much more difficult.

          Job Titles become mere vanity seat cushions on the team bandwagon.

Leave a Reply

Your email address will not be published. Required fields are marked *