IT Basics - XML, XBRL and Liz Hurley's socks. By Simon Hurst

ebdex Document Exchange may be the only transaction hub built purely on eBis-XML!

Why did we choose eBis-XML instead of any other standard, from EDI to UBL, cXML, ebXML, etc?

The key reason is BASDA. We felt that there would be significant take on of this particular standard by UK based finance software vendors.

However, cXML and others have recently had much more publicity due to OGC.

So, have we chosen the wrong standard! Hardly the case.

The only complaint I have with eBis-XML is that it only has a draft schema for remittance advice. So, we are having to create our own schema.

Best regards
Manoj

Manoj Ranaweera
CEO - ebdex Ltd

Don't forget there is always a price (trade-off) to be paid for XML etc. interoperability between systems.

In the case of 'tagged' records/fields the overhead is actually the very thing that makes life easy; namely the 'tag' itself

For example suppose one has a price of £10.55; then depending upon the 'tag' names chosen the information associated with a simple number can far exceed the size of the data iself

i.e.
'NetPriceOfProduct'
10.55
'/NetPriceOfProduct'

(substitute ' for Greater/Less Than signs)

So we have the data size = 5 characters and the tag size = 38 characters - in other words the 'tag' is nearly 8 times the size of the data

The real issue is a hugely 'bloated' file than can easily run to many times the size of the actual data; at this point one relies upon data transfer speeds (broadband, Cat5 100Mb etc) to compensate for the overhead of 'tags'

Basically it is down to balance - one technology cannot necessarily be advocated in isolation, without taking account of the entire picture. Like all ideas XML has its place in the scheme of things but one needs to be aware of all the issues

This article provides a useful overview but I think it's worth clarifying the differences between XML and XBRL and emphasising the real purpose of XBRL because I think the article seems to lose its way a bit toward the end.

XML is a specification of the mechanics of how tags should be formed. That is, they will start with "<" character and end with a ">" character and so on. XML is an enabling technology but it is it not directly useful in its own right. What is needed for XML to be useful is agreement on the names of tags that will be used in a given circumstance(a language of sorts) so that the data generated by one application can be understood by another. This is what BASDA has done, what TaxML does, what Microsoft's SpreadsheetML and what many other XML tag sets aim to offer.

Take the example given in the earlier post. JC makes the point that there can be "bloat" using XML but the benefit is that the data value "10.55" can be labelled. JC gives the example of labelling this value "NetPriceOfProduct" so a consumer of this XML snippet is given more contextual information about the value. Critically, this labelling can be extended to include, for example, "productname", "denomination" or whatever else two parties agree is needed for the meaningful exchange of data.

In XBRL sets of agreed tag sets representing UK GAAP, IFRS or US GAAP are known as "taxonomies".

The purpose in creating taxonmies isn't really to make the job of HMRC or any other regulator easier. It's to help make sure that when a consumer of a set of financials presented via XBRL sees a value tagged "NetProfit", whether that consumer is a regulator, an analyst or a member of a finance team, the consumer:

a) knows what meaning this value is supposed to convey; and
b) can compare the value of this tag for company A with the value referenced by the same tag for company B with a reasonable assurance that the two values will have been computed using the same principles.

Many companies create taxonomies and one that some of us will have become familiar with in the coming years are the ones produced by Micrsoft for the new version of office.

A key difference between the taxonomies generated by a private company like Microsoft and those generated by the bodies involved in developing XBRL taxonomies is that the XBRL taxonomies have to be agreed and accommodate the history and the interpretations that accompany all GAAPs.

It is great that BASDA has created a standard. But by definition it is a British standard while XBRL taxonomies, such as the one created by the team at the IASB, may have to cover the world.

JC, of course you're right. Even if we extend your example:

<Product>Shirt
<Color>Red</Color>
<Size>XL</Size>
<Style>Beachwear</Style>
<InStock>Y</InStock>
<Price>10.55</Price>
</Product>

compared to a CSV file which looks like:

Shirt,Red,XL,Beachwear,Y,10.55

...the inefficiency is broadly the same. Add "real world" data including binary information and you can understand why compression is a much researched subject.

However (there is always a but..!), when you combine XML with the right tools (e.g. web services, XSLT) some amazing things can happen. Only this week, I have made it possible for a client to push information from their CRM system onto their website.

Even five years ago this could have been weeks of work, and would have been pretty unstable to boot. It isn't just the fact that the information wouldn't be in the correct "format" - there would simply not be any mechanism where one end could send data to another - so it would all have to be invented from scratch.

Now all I do is build a web service on the web server to consume the XML feed which the CRM system happily provides, whilst XSLT is employed to transform one "format" of XML data into another that the web site understands. The basic prototype took two hours, the whole thing was finished just after lunchtime...

That's not being clever. Accompanying XML is a whole new world of tools and technologies which enable developers (and sometimes even users) to do traditionally very complex tasks very, very easily.

<tagline>
CSV is dead. Long live XML! :)
</tagline>

Stewart
stewart@bawden-quinn.co.uk

Bill, thanks for emphasising the difference between XML and XBRL. As I understand it, XBRL is specifically confined to international reporting standards for the stock exchange - fascinating if you're into that sort of thing. But XML is universal and will affect us all.

One question I wanted to put to JC, Stewart, Simon. Theoretically, XML should make it possible to send a sales order from one accounts packager to another package, and the second package can "read" the order and update its files accordingly. Interoperability.

However, I was talking to a package vendor last week and he said that vendors were developing their own versions of XML. As a result interoperability was being lost. He could send an document to one of his own dealers (who uses his package) but not to a dealer using a different package.

Since interoperability is the whole raison d'etre for XML, this could kill XML if it continues.

Are multiplying versions a problem?