Xml At Organization Boundaries

An XmlPattern?...

XML is an inefficient format: it is neither as space-efficient or as fast to marshall as a binary format. System components that are sensitive to latency or bandwidth usage are better off using some (perhaps proprietary) binary format.

However, XML is a standard format. There are many useful tools for processing XML, such as XSLT which is used to define translations from XML into other formats. XML tools and libraries are available on many platforms. This makes XML a good format for sharing data between organizations.

Therefore use an efficient encoding for data flowing within an organization and translate into XML when data needs to be published to other organizations.

-- NatPryce

Discussion

Applying the pattern recursively yields the following strategy: each organization is composed of departments, each of which has its own information systems, and therefore functions with respect to other departments much the same as a 'foreign' organization. Therefore, use XML for data flowing between departments of an organization, and an efficient encoding within the information system of one department.

But a department's information system is further decomposable into smaller subsystems, each with data that is in one sense "foreign" to the other. Therefore, use XML for encoding any data that is exported by a subsystem at some point of its lifecycle; use an efficient encoding (such as the compiler's or the VM's internal representation of object graphs) for data that is never exported.

Why would you want to apply this pattern recursively?

By exporting XML from every subsystem, as you suggest, you are falling into the same problem this pattern addresses - that using XML everywhere is too inefficient for use between subsystems. (If subsystems are not sensitive to latency or data size, then it doesn't matter because that is not the context of this pattern).

A single organization typically has one department that is responsible for developing systems for other departments. If not, a single team can be responsible for maintaining libraries that implement an efficient proprietary encoding used by other departments. Either way, a single organization can enforce a policy that systems communicate using an efficient protocol. An organization cannot force other organizations to use the same protocol, so you have to use standards for data passed between organizations, and XML is reasonable for that.

IMHO you are making unwarranted assumptions as to where the boundaries lie across which the use of a LinguaFranca is necessary; the suggestion to apply the pattern recursively intends to make those assumptions apparent, by pointing out that within the same organization or even within the same department, it may be (and often is) the case that incompatible internal formats of various subsystems make the use of a common, standardized format desirable.

The pattern isn't saying that one should not use a LinguaFranca within an organization but that one should define an efficient internal lingua-franca (enforced by organization policy if need be) between subsystems that are "sensitive to latency or bandwidth usage". In that context, XML should be reserved for publishing textual data to other organizations, because that's what its good for. It's pretty poor for defining presentation-layer formats.

If an organization is not passing data between subsystems that are sensitive to latency, parsing overhead and bandwidth usage, then XML is reasonable as an intra-organization LinguaFranca. However, such situations are not addressed by the context of this pattern.

Potential Consequences of using XML at all

XML allows and forces many people to define their own languages and grammars for these on top of XML using DTDs. This means, many relatively inexperienced language designers create new languages every other day. The current market urges them to emit and standardize their XML-based language specifications before they got enough experience to see what works and what does not work. I see this situation as even as dangerous as the overhead inherent in processing XML. May be we should say XmlDtdDesignIsLanguageDesign?.
XML DTDs might imply a manifest typing of data across interfaces. This can hinder advancement in the associated components and introduce code bloat as well as a version dependency change management nightmare.

May be these more social things are more important than just the processing overhead inherently in a language with XML's structure.

-- PeterSommerlad

There is nothing XML-specific in the problems listed above. The same problems occur in the definition of object interfaces, APIs and non-XML data formats. As soon as you need to publish data or components for use by other organizations, or even other teams, the format becomes harder to change.

Yes, social issues affect the development of systems, and the use of immature standards such as XML. However, that is beyond the scope of this small pattern. Feel free to patternize solutions and link them into the rest of the XmlPattern?s, ComponentDesignPatterns, etc.

CategoryXml, CategoryPattern