Strumenta 
Why this interview?
Campbell Pryde is the CEO and Presiden of XBRL US, a global standard for reporting financial data for business and government, used pretty much in most countries around the world. In this interview, with Campbell Pryde, we try to find out more about XULE a rules language for XBRL.
Here there are some quotes I found particularly interesting:
[…] one of the things that we wanted to do was to basically write a rules language for XBRL, so that we could then write a lot of these rules a lot faster, and a lot more efficiently make debugging of those rules easier as well.
[…] the syntax was really designed in a way to make it as easy as possible to write, but at the same time, make it easy to debug and to understand, and to take up as little, to be as precise as we possibly could. And one of the underlying drivers for that was in theory, was to make it possible so accountants could write these rules and they could read them, or any other person who was like a data scientist. They could read it without necessarily having to go and learn a complex programming language to read the stuff.
[…] XBRL specification has evolved, so now you can get XBRL data in a JSON format, or you can get it in a CSV format, has something called inline XBRL, which is effectively XBRL data in a HTML format.
[…] we wanted to make it easier to pull multi-dimensional data and understand what those dimensions were.
[…] So if you want to, you can set it up so that you can point it to different taxonomies so that you can check it. So it’ll work with any taxonomy. So if you’re in Italy and you’re using IFRS, you can use it for that. It’s really not a US thing at all. So if you want to use it with any taxonomy, anywhere in the world that’s been published, then we’ll work with this tool as well.
[…] And it’s been very useful for improving the quality of the XBRL data, so particularly for the SEC data. So now that makes that data much more useful for other purposes. So people, as the quality gets better, more people start to use it. People use the data, they find issues in the data. They let us know, we’ll add a XULE rule, that’ll get fixed, more people start to use it, so it becomes the cycle, but we kind of needed to do that.
Federico Tomassetti:
So, thank you very much Campbell for taking the time for this interview. I’m very happy. And how are you today?
Campbell Pryde:
I’m good. Thank you for inviting me. I’m looking forward to talking about XULE.
Federico Tomassetti:
Good, good. And we will indeed talk about XULE, but before that maybe we can start explaining a little bit the context, and maybe you can talk a little bit about yourself and your organization.
Campbell Pryde:
Great. So just to give you some background. So XBRL is a global standard for reporting financial data predominantly, and it’s used pretty much in most countries around the world. Across Europe, there’s a big rollout of XBRL for public companies at the moment. It’s used heavily in Asia and in the United States, and also in Latin America, and also in the Middle East. It’s predominantly used by banking, regulators and securities regulators, but it’s also used by tax regulators as well. And the main purpose of it is to collect financial data. And this might be things that you’re familiar with, like a balance sheet, income statement, cash flow, that kind of information. Anything which is used to measure the performance of a business. So that’s what XBRL standard is used for. And throughout the world, there are a number of different jurisdictions who try to help people adopt XBRL, and then the US where we’re based, and that’s what we do.
Campbell Pryde:
So we predominantly help people like the SEC, which is the securities regulator here in the US, we’ve also help the Federal Energy Regulatory Commission. They’re the regulator who regulates the utilities industry or the electric gas and oil pipeline business. So they take financial data from their regulated entities and also a banking regulator called the FDIC, which is responsible for ensuring bank deposits in the US. And so they take a lot of financial matters as well. So, all of these entities are using XPRL to collect data. And once they collect it, then they make it available to people to use. So that’s kind of what we do is XBRL US, we help those regulators do it, but we also help people file to the regulators, and training and tools and trying to build a community for people to do that.
Campbell Pryde:
XBRL US itself, is a not-for-profit. We basically report into XBRL International, which is also a global organization, which is responsible for the experimental specifications. So, they basically will publish out the XBRL spec, which some of you may or may not be familiar with. You can go to their site, you can see all the specifications. And all those specifications do is really define a format about how a company should report their financial data to another entity who is collecting it. Usually a regulator, but it could also be anyone who’s in financial data, which lots of people do that. The insurance industry does it, or private equity, or whoever it is. So the standard can be used for many purposes, other than those ones I’ve just discussed. They’re just the main users globally.
Federico Tomassetti:
Yeah. And for example, Strumenta is a small Italian company, but after we talk, I looked into XBRL and I realized that for example, our financial data, that must be public. I mean, this is the case for all companies in Italy, as being also specified with this format. Yeah, so it’s quite widespread. Good, good. And so, I think you already covered what is the format, we is using it, and what is the purpose. So, I think you laid the perfect context to now explain what XULE is.
Campbell Pryde:
Great. So, one of the things that we’ve tried to do, one of our missions, one of our core goals is to try and make a lot of this expert data available to as many people as we can. And in the US predominantly that’s investors, but also we want to make it easier for regulators to use that data as well. And we undertook a number of initiatives. The first initiative we undertook was to basically start collecting all this data, and then make all that data available to folks out of a database. And we made an API and you can look at that. So you can bring the data back and you can look at it in things like Excel, or any other tool which can talk with an API and build an application, et cetera. One of the things that we found with all of this data being collected, the data, unlike traditional data formats, or traditional data that’s collected, financial data is very, very complicated.
Campbell Pryde:
And so, there’s a lot of complexity there. So to be able to collect this data and collect it accurately, can become problematic. So, one of the things that we wanted to do is to try and improve the quality of the data that was being reported to folks like the SEC. And the SEC is a little bit more complicated, because companies have the option to basically go and define their own metadata, which allows them to report things that may be unique to them. So if you can imagine you’ve got a model, you’ve got a data model, that the SEC publishes with the financial regulator, which is the FASBI here, the Financial Accounting Standards Regulator. They basically then define a model and they say people have to report on it, but they do give companies the option to extend that model, so they can then take the model, add some additional metadata to it, and then report to the regulator. And that’s what’s happened in the US. That’s also happening in Europe as well.
Campbell Pryde:
And this is typically done, not by banking regulators, but mainly by securities regulators. So, if you want to understand the data that’s being published, you need to be able to navigate these models. You need to be able to read them and you need to be able to apply logic to them. So, one of the things that was published by XBRL International was something called XBRL formula. And this is a way so you can define a formula relationships between data and also metadata, and use metadata to define those. There are a number of deficiencies in XBRL formula. Well, not deficiencies, just scope areas that it didn’t cover. The standard was also defined as an XML format, so it was a little bit difficult to express and to debug. So, one of the things that we wanted to do was to basically write a rules language for XBRL, so that we could then write a lot of these rules a lot faster, and a lot more efficiently make debugging of those rules easier as well.
Campbell Pryde:
So, we came out with something called XULE, which was really short for XBRL rules. So, that’s what it’s called XULE. And then at the syntax was really designed in a way to make it as easy as possible to write, but at the same time, make it easy to debug and to understand, and to take up as little, to be as precise as we possibly could. And one of the underlying drivers for that was in theory, was to make it possible so accountants could write these rules and they could read them, or any other person who was like a data scientist. They could read it without necessarily having to go and learn a complex programming language to read the stuff. Secondly, we wanted to put a lot of functions into the language so that it would make navigating the XBRL model very easily and intuitive. So, that was the genesis of doing this. That’s why we did it. It was really to get better quality. As we’ll talk later, it actually has a lot more uses than that as well.
Federico Tomassetti:
So, if I understand correctly, a lot of companies and institution provide their financial data in this format. And so, its very interesting to be able to access this data and to process it for very different doctors, I guess for example, for tax purposes, maybe one wants to do some calculation. But also, someone may want to process this data to assess the financial health of a company, or maybe even for internal users to understand how the company is going, maybe calculate indexes and guide decisions based on this data. And I understand that originally was created XBRL formula that is written in XML, so it’s a format that is great for machines, but you instead wanted also to provide a language that is more user-friendly, so that these many different doctors can use it to actually process the data, to query it, to calculate values and get information out of this data.
Campbell Pryde:
And one of the other issues I didn’t really mention is we’ve written it, it’s in the XML, but it expects to some extent the data that is provided to be in an XML format as well. Now, XBRL has kind of moved on and it’s tried to remove or separate more clearly the semantics and the syntax of the model. And so, XBRL specification has evolved, so now you can get XBRL data in a JSON format, or you can get it in a CSV format, has something called inline XBRL, which is effectively XBRL data in a HTML format. So the XBRL formula when it was first written, has a lot of syntactical artifacts in it, which refer to XML type constructs. Whereas when we did the XULE language, we tried to remove as much of that syntactical reference as possible, so that if XULE would work whether the data was submitted in JSON or CSV or HTML.
Campbell Pryde:
And so it works fine on any of those different, if the data is provided in that different syntax, it doesn’t really matter. There’s no real artifacts on the XULE language that directly references them. I would say that there are some, that sometimes you want that data for a specific purpose, but we try to avoid putting that into XULE at all so that we’re not in a position where you need to rely on the format being in a particular syntax.
Federico Tomassetti:
Yeah, because I understand that the people who have the competence to ask the right questions are typically not developers. They’re accountants, people that understand about finance or taxes. So yeah, probably they are not XML experts. And so, if we can provide things in a way that is more user-friendly, we make their life easier. And can you tell us something about the design of the language, its history, who has created it?
Campbell Pryde:
So, I used to work for Morgan Stanley, and one of the issues we’d had there was also similar. We’d tried to write languages to basically process this data. And one of the tricks of this is really processing multidimensional data. XBRL uses a dimensional model. And so, how do you reference data that’s in a multi-dimensional structure. And then, doing that in a way without being buried in hundreds of four loops. So that was one of the underlying design principles, is we wanted to make it easier to pull multi-dimensional data and understand what those dimensions were. And at the same time, XBRL, you can think of it is, this is kind of really before graphs really came about, but it really is a graph.
Campbell Pryde:
The XBRL model is really, it’s based on length, so it’s really linking nodes to two other nodes with arcs or networks, so you can think of that way. So you have two parts to it. You have this network which defines the model, and there’s multiple networks which can define the model. How things add up? How are things presented? What’s the relationship between these two concepts? Is this type of this, is this of this type that? There’s a lot of relationships that are defined in the model. Then at the same time, you have a lot of factual data, which is then reported based on that model. And so, what we tried to do is we said, “We really need a language which can allow us to access the model easily, and allow us to access the facts easily, and then combine them together, and then create different information.”
Campbell Pryde:
And the reason that’s important is because you may have the same data being reported at multiple places, and you might have data reported that one’s a component, one piece of data’s a component of another piece. But if you want to add something up, you don’t want to double count. So there’s all this complexity there, or you only want to add items which have equivalent decimal accuracy. So, to be able to understand which concepts relate to each other, and then what facts were reported to them, and how they’re dimensionalized, you need to be able to manage all that. So, XULE was initially designed. We sat down, I was in Guatemala at the time, and I think Philip (Philip Engel – Data Architect / Data Engineer at XBRL US, Inc.) at the time, he was in California. And then we said, “We really need to be able to address all these different things.”
Campbell Pryde:
And so we just sat down and went through everything that we needed to be able to do to address this. And we ended up with like a 100 page specification.
Federico Tomassetti:
Okay.
Campbell Pryde:
It was very precise. It just dealt with all of the issues. How do we navigate these networks? How do we pull the facts out? How do we handle dimensions? What functions do we need? What properties do we need? What’s the type of stuff that we’re going to need to be able to do. And we had a lot of experience with this in terms of looking at data that the SEC had reported. Looking at the stuff that we had done at Morgan Stanley. And so, we kind of knew what we needed and how we need to pull that data out. So a lot of it was really just designing the syntax of language, and how can we do this in the most efficient way possible? At the same time, without having a syntax that was ambiguous.
Campbell Pryde:
So that was kind of what we sat down and did. So we wrote this document, and then we said, “Let’s try and implement it.” So we build a parser to do that. And then we wrote a processor in Python, and then underneath it used software called RHEL, which is just like an open source XBRL processor. And then we could basically, we would then just basically did the grammar and then we could compile those rules and then we can run those rules. And then we went from there, and then we kind of gradually went through a whole bunch of use cases and refined those. And then we came up with a finalized syntax. And we had a processor that basically worked. And then went from there and refined it. So that was kind of the history of it. So, myself and Philip Engel really spent a lot of time on the design, and then trying to get this thing to work.
Federico Tomassetti:
Good. Good. And is there any project you are aware of that is using XULE, and that your team could be interested to share?
Campbell Pryde:
Yeah. So there’s a couple. One that we have implemented here in the US, is we produce a number of data quality rules, which we publish. And we publish those rules in XULE syntax as the raw syntax, but we also published a compiled version. And then folks can take those and then they can process those rules against a filing. So for example, let’s say I’m a Fortune 500 company, and I’m going to report my filing to the SEC. We try to encourage people to run these XULE rules before they file with the SEC. They’re freely available, so people can run them. And then what that does, is they’ll run them and they’ll see if they’ve got errors in their filing. And if they do, then it gives them a message. This is the issue, this is probably what we should do to correct that.
Campbell Pryde:
Then they can correct that, then run them again. And that there’s no errors and they’ll file it with SEC. Now, this is the initial design purpose of this that we wanted to achieve, because we wanted to improve the data quality of the filings with the SEC. It wasn’t necessarily consistency across filings. So these rules were designed to do that. Now, the SEC had rules as well, that were really more, think them as more like XBRL syntaxtical rules, XBRL valid, but these rules are more like really looking at things like your balance sheet balance, or have you paid out? Does your cashflow calculate the way it should be? Have you added something when you should have been subtracting it?
Campbell Pryde:
So it has a whole bunch of rules, or there’s inconsistencies between these types of elements. We would expect the first quarter, second quarter, third quarter and fourth quarter to add to the total of a year. So all of these things, these rules can be expressed in XULE, and then companies can run them before they file. And then that way they can improve the data quality. So pretty much, I would say the majority of the largest, 2000 filers are using these rules today, before they fall to the SEC. And then we’re working with software vendors to integrate the XULE into the software as well, so that they can all run these things.
Federico Tomassetti:
Yeah.
Campbell Pryde:
So that’s one. The other one is Federal Energy Regulatory Commission. They are also using XULE, and they’re using that for validation, but they’re also using it for rendering HTML documents. So, and this was never the intention of XULE, but it actually works really well for doing this, is so we create HTML templates. And then we take the XBRL data, which is coming in, in an XML format. And then we take XULE, and it basically pulls the data out of the XML. It takes data, it pulls out of the taxonomy that they’ve published, and that plonks it into a template, an HTML template. And then you can just open the HTML. So it’s basically acting like a style, like a FO type style sheet that some of you may be familiar with. But what’s nice about it, is if you make changes to the taxonomy or the model, then the rendered template is going to change.
Campbell Pryde:
If you change the document, then that data will change. And if you’ve got the same data that just reported or multiple schedules, you can change it once and it’ll update it every year. So it’s just using the ability to read the taxonomy and read the instance style data, and basically take that data, manipulate it and use it for something useful.
Federico Tomassetti:
No, I think it is very inspiring to think that so much data is available in this format, so when you create some useful tool, for example, to validate the quality of the data, or to present them in a readable format, you can operate at such a scale and this tool can be immediately useful for, well, probably millions of companies across the world. So that’s very inspiring, yeah.
Campbell Pryde:
Yeah. The other thing we actually did it for, we used it was actually it was just the easiest way to do it. We had a taxonomy and someone said, “Oh, we want to publish this as an open API using the swagger format, or open API format.” And we wrote a XULE rule that would take a taxonomy and output it as an open API, which is kind of interesting too. So it’s just really a way to take data, reorganize it and then output it based on all the input data that you’ve got.
Federico Tomassetti:
Good. Good. And we have talked about XULE, but one project also that you have created is the editor for XULE. And can you discuss about the goals of the project?
Campbell Pryde:
Right. So we initially started creating these rules, and one of the problems became, as the rules became more complicated and you wanted to do stuff, it became very difficult to one, write the rules. You had to know, oh, there’d be an error. You’ve got to compile it. You get a compile error, then you’d have to come back and you’d have to read through all this text and say, okay, where’s the problem here? I can’t find that. And trial and error, trial and error. And it might take, you might write a rule, and it might take you several days to write this thing. And most of the time, 90% of the time was finding, oh, I put a mistake here, or I did a mistake there. So there was no real tie, you had to cycle through a compile cycle. So there was no IDE for it.
Campbell Pryde:
So one of the things we said, this is really bad and this is just taking way too long. So, we contacted Strumenta, who we had worked with in the past, because we had looked to do something, some other project with them. And we knew that they would do a good job, and we knew that they knew what they were talking about. So that was good that we had that contact. And so then, we sat down with them to look, well, let’s start this. We just really need to start with an editor. And then let’s see what we can get that working, so that we can actually start to write these rules. We can know they’re valid before we actually compile them. And then we can save a lot of time in terms of going through this, trying to debug these rules to get them right.
Campbell Pryde:
And so that’s what we did. And so we sat down and we went through, and I can’t remember how long, it probably took like a month or two months, was it? You may remember better than I do, Federico. And we went through and we basically took the document that we’ve got, which is basically defines all the syntax. And then we went basically through and we created this editor, Strumenta created the editor, and then we would go back and test it and then come back, and made us realize the stakes in our document. We had a few of the fixes we found from going through that process, so that was actually very good as well. And what the editor did, is it basically would color highlight everything, color highlight the functions and FactSets and all these different aspects of the XULE language.
Campbell Pryde:
It also did checking against the taxonomy. So if you put a concept in, and it wasn’t on XBRL concept, it would highlight that for you. So then you could basically, typos were a big problem, or sometimes there’d be elements in one taxonomy that didn’t exist on a followup one, because it had been removed. So, checking for all of us became probably it increased our efficiency by at least 1,000%. It made a huge difference. This is one of the things that we did. I am so glad we did because it just saved us so much time.
Federico Tomassetti:
Good. And yeah, and I think when someone creates a language for someone who is not a developer, I mean, the bar is much higher. I mean, unless you build these tools to help them, its difficult because it’s not their profession to learn the language. So, and maybe they don’t use it every day. So, if they can have a tool helping them, you can yeah, help them.
Campbell Pryde:
Yeah. It makes a huge difference. And just, we have the auto complete on there, so that’s really useful. So it can audit the elements, you don’t have to go and look them up. It’s just like so many savings across the board. And we try to, when we write rules without using the editor, it’s almost, if you try and do that, I always go and copy and paste a rule that’s not in the editor, just even to check that the rules right, rather than go to the parse. It’s just easy to go through the editor. And it’s also because it’s color coded. It makes it easier to even think about the problems, and just the process of writing a rule just becomes easier, because your mind, you’re not consuming bandwidth with worrying about getting everything to work.
Federico Tomassetti:
Good. Good. So, at this point we could show a demo of the editor. Okay. [DEMO] Now, at this point we will set up the demo. And okay, now maybe we can discuss how can people get the editor, and how can people learn about it?
Campbell Pryde:
Okay. So, the editor itself is, we decided to write it in Visual Code, which is a Microsoft product. We’re not pro Microsoft or anything like that. But the reason we chose that software to do it, was just because it’s very high usage. That’s probably one of the most commonly used IDEs out there. It’s pretty quick. And a lot of the other editors… You don’t have to pay for it, it’s open source, it’s freely available. And then they have like a lot of libraries and it’s relatively easy to basically to be able to update extensions. So we could add it as an extension into the Visual Pro editor, so that was one of the reasons we chose it. We had used different editors, so we kind of switched to use it as well. And so I think that that was a reasonable choice.
Campbell Pryde:
We don’t have plans to put it into any other editors, just because it’s not really forcing anyone to buy anything to do it. So you can go out and get. You can download it, and then you can just look up XBRL, or you can look up the XULE and in the extension library, it’ll come up and then you can add it. And then you’ve got the XULE extension in VS Code. It’s very, very easy to install, and very, very easy to start using. So, there are a number of users are using it. The Federal Energy Regulatory Commission, they using it to write rules. And their environment, it’s very difficult to set up software, but setting up with XULE editor by far and away the easiest thing to set up, because they were using code, or your Microsoft shop, so I made it very, very easy to use.
Campbell Pryde:
So I haven’t seen anyone have problems implementing it. It seems to work through, to do that install, seems to work through most firewall setups, pretty seamlessly. So, in terms of using Visual Code, I think that was a good choice. I know Strumenta obviously they, I’m not sure how much experience you had before that, but they were very good in sorting things out and getting things to resolve. There was some complexities in using it, particularly checking what taxonomies that were used and what were the elements that were there. So they did a good job doing that.
Campbell Pryde:
So if you want to, you can set it up so that you can point it to different taxonomies so that you can check it. So it’ll work with any taxonomy. So if you’re in Italy and you’re using IFRS, you can use it for that. It’s really not a US thing at all. So if you want to use it with any taxonomy, anywhere in the world that’s been published, then we’ll work with this tool as well.
Federico Tomassetti:
Yeah. No, I think it’s interesting the fact that there are so many aspects to consider when choosing a platform, like for example, you talk about how difficult is it to install certain custom software on certain environments. So maybe using something like VS Code that is a widespread, make it easier and install the extension within VS Code its easy. And maybe also not a reason why in a similar project makes sense, in my opinion, to choose VS Code is that it doesn’t take too many resources. So it takes much less resources that alter ID that our target developers. And the problem is that typically developers has more powerful machines than other users. So if you don’t take these into account, your intended user could have problems actually, using the editor.
Campbell Pryde:
Yeah. And that’s how we found that the Federal Energy Regulatory Commission, we laid it out to a lot of people. They were just really, there were various business users, they were developers. It could be installed on very low end spec machines. It works totally fine. It’s not power hungry in any way, in terms of the memory or the processing power.
Federico Tomassetti:
Yeah. And is there something that you have learned from your users about the language or the editor or something that you decide to change after the first release of XULE or the editor?
Campbell Pryde:
Generally, we haven’t changed very much at all, and time to time things come up where we may need additional functions. One of the things about XULE, is you can define your own functions as well within there, but so if you need a function to do something, you can just define that within XULE. And we’ve written a couple of those, like if we want to check an ICE is valid, which is a security identify a code, or we want to check that kind of thing, we actually wrote functions within this syntax to do that. So, a lot of that kind of stuff, which is very domain specific, you can write those functions. Some, we have added some functions around regular expressions and looking up terms. So we’ve added a function for that in the underlying XULE processor.
Campbell Pryde:
So, and we added a function, I think it was a true function. We had case where we were adding white space in there. And so we actually updated the underlying code that was provided Strumenta just add that functions. It’s relatively easy to add a function into the IDE so it recognizes it and it comes up. So that hasn’t been a problem. So, obviously if we had to do a total redesign of the language, then obviously we would have to republish the IDE. But generally, most of the changes have been things like, we meet to add a new property, because we decided we needed this to be property like a trim on a string. Or we wanted to add regular expression matching, for example, on a string as well. That was just something we didn’t have.
Campbell Pryde:
And that just came up, because as more people wanted to look at the string data, that was just another functionality that we thought we should implement. Most of that functionality, it follows, if you’re familiar with Python, we’ve kind of modeled in a way based on the way that Python handles data. So it includes, its handling of sets and lists and dictionaries is literally identical to Python. So if you’re familiar with Python, a lot of the terms are similar, but we’ve tried to take the complexity out of it. So if someone’s good at doing things like Excel functions, this stuff’s not going to seem foreign to them at all.
Federico Tomassetti:
Good, good. So it seems that your initial design of the language proved to be right, and so you did just incremental changes, of course.
Campbell Pryde:
Very few changes, and it’s interesting is we can handle pretty much, it handles pretty much most situations. Well, pretty much all situations we’ve run into at this point. It hasn’t really been… and if it doesn’t, then maybe there’s a better tool that you should be using. But in general, we try to be as inclusive as we possibly could and get every possibility that we knew about. And so I think that generally has worked. And there’s been no… The only changes to the grammar has been to add a property here and a function there.
Federico Tomassetti:
Good. So it seems that the language is pretty stable. So I was wondering if you had any plan for the future, or a few new feature or upgrade, or do you think that the language and the editor works already quite well and so on?
Campbell Pryde:
One of the things that we are looking at updating is in the XBRL world they’ve released the new specifications for a CSV file. So you can express CSV in XBRL. And this means that some of the files you get are significantly larger. In fact, you could have files which are a constant stream of data, the way that the current, the XULE processor works is it pulls all the data in, and then it runs its validation on the data that is in a file, right? However, if you’ve got large continuous data files, let’s say you’ve got a continuous stream of data coming in, let’s say its coming from stock feeds or whatever it might be, but you want to validate those. And in some cases you can’t really wait until the entire file comes in, and the files are too large.
Campbell Pryde:
So one of the things we were looking at was adding functionality to XULE for that. So it would be doing validation on the stream as it comes in. That has some implications in the sense that you have to write rules a little bit differently. If you want to compare things to aggregate totals, you have to be running aggregators in the background, aggregates stuff as it comes in. So that kind of stuff, we’ve sat down and started to write, how would we write validation rules? And if you’ve got a record came in, obviously you can validate that record. But if that record has got references to other files, then there’s a sequencing type things that you need to address in the language as well. So those are some things we’re looking at updating. That’s one particular area, which is actually going to be quite a bit of work.
Campbell Pryde:
The other thing we’re also looking at is the ability just to bring in modules, I suppose, would be the right word for it. So let’s say someone’s gone and written a bunch of functions in XULE. When you compile those rules, you’ve got to take all those rules and you kind of put them all together into a folder or a folder structure, it’d be nice if you could just reference those, lets say they’re on a URI on the web, someone’s financial functions would be nice just to be able to import those when you compile the rules. So that’s the other thing we’re currently working on at the moment, its like an import function. So there was a couple of things that would be relatively easy to do, compared to the streaming stuff, which is a major deal. So we’re kind of holding off on that for now. But the modules is something that we’ll probably be implementing in the next two months.
Federico Tomassetti:
It’s interesting because I think that both streaming and module side, the kind of things that you may want to add to a language as it becomes more stable, more use, or is part of the engineering phase.
Campbell Pryde:
Right.
Federico Tomassetti:
It’s coherent with the fact that the language is proved to be well-designed, and so it’s getting more and more stable, so nice.
Campbell Pryde:
And one of the design principles is we don’t want to make it too complicated so that you’ve got to have all the setup, and we want people to be able to pick it up and they’ll run a real quickly and then be able to do stuff. So, there is trade-offs there, so we’re constantly very aware that we want to try and make it as easy as possible for people to use. And people can look at it, and we’ve had people comment that, not so much on the editor, but on the language itself, people have given, we’ve made the whole thing is available on GitHub, so you can go to GitHub. So we’ve had a number of comments from people who have been using it, particularly filing agents, a company who runs software. They have implemented it and been using it on their site.
Campbell Pryde:
And if they see issues or they see performance enhancements and they’re giving us stuff as well, so that’s so good feedback. Technically XULE it’s not an XBRL standard. So we’ve kind of launched this as an open source initiative, just to give people a tool that they can use to manipulate XBRL data and produce output file.
Federico Tomassetti:
Good, good. And I think it takes some discipline sometimes to keep the language simple and not just say yes, being too enthusiastic. Good, good. And is there any other tools that work with XBRL that you think our listeners may want to look into, or that is useful to them?
Campbell Pryde:
So we’ve worked also with Altova, some of you may be familiar with. And they’ve implemented XULE in their XBRL package as well, that’s part of their software solutions. So they’ve done it too, so we’ve got that. And then we’re working with a number of other software vendors to help them try and implement it. Most folks who have implemented have been software providers in the reporting industry, particularly in the US. And that’s because they want to run these rules locally in their software, before people follow with the SEC. So we’d published them out. So what a lot of them would do is they might have a gooey interface where people prepare their filing, and then if they make a mistake, the rules are running in the background and it’ll come up and say, “Hey, you’ve made an error here. There’s something wrong. This doesn’t make economic sense.” Or, “We would expect if your liabilities are X and your assets are Y, that this would be within this range, or that your reported amount, which shouldn’t be negative. How could this be negative?” So those rules are kind of incorporated into the software as well.
Campbell Pryde:
So, we were helping a lot of these software vendors provide that language into their software. And ideally the way that the software should work, it’s not always the case, but the way that the software should work is that they can then just upgrade those. We can publish out a new set of rules, and I can just update their software. Then they’ll have new rules in their software. So that’s kind of the way we’re trying to make it work. So it’s not like everyone has to go and re-code rules into their software. That would be, it’s very, very inefficient. So that’s kind of what we’re trying to get to.
Federico Tomassetti:
Yeah. So, through collaboration with the software vendors, a lot of people can benefit from your work on XULE. So that’s a very nice yeah, a really nice thing, I think.
Campbell Pryde:
Yeah. And it’s been very useful for improving the quality of the XBRL data, so particularly for the SEC data. So now that makes that data much more useful for other purposes. So people, as the quality gets better, more people start to use it. People use the data, they find issues in the data. They let us know, we’ll add a XULE rule, that’ll get fixed, more people start to use it, so it becomes the cycle, but we kind of needed to do that. And having this language available, it has made the data quality much, much better, and Strumenta has been really helpful in terms of getting that editor. That’s probably meant that we’ve been able to get 10 times more rules out than we would have been otherwise been able to do. And it also means that the tool can be used by others. We couldn’t give this to people without having a nice IDE to use.
Federico Tomassetti:
Good, good. Well, thank you all for saying nice things about working with us, I appreciate it. And now we are reaching the end of our interview. So, I wanted to ask you if there is anything that you wanted to add, anything I forgot to ask you?
Campbell Pryde:
I think, the only thing I would add si, I think we’re just scratching the surface in some of the stuff we can do. We currently have projects that we’re working on to take this data and then to normalize it, that basically means take those data report in XBRL format, and then repackage it. The tool, the ability to do this as quite powerful, particularly when you’ve got lots of networks and things like you may have heard about this, there’s big talk about graphs and navigating graphs and doing data for that, graph APIs and all this kind of stuff. But XULE was actually, from what I’ve seen, is one of the best tools to do it. We spend a lot of time working out what’s the best way to navigate networks, so we put a lot of functionality into that.
Campbell Pryde:
So if you’ve used tools in the graph databases, they have some of these similar SQL type queries, how you can navigate a graph. We’re spent a lot of time, it’s not like SQL because I will try to make it as close to SQL as we could, so that people who understand that concept of data, can make the mental leap a little bit easier. But then for the graph navigation, we’ve tried to make it a similar way that you’ve navigate a graph node.
Campbell Pryde:
I start at this node, I go down this node. One of the things that we have in XULE, which is really useful, is you can check the properties of attributes on those arcs. And then that can then control which arcs you go down. It also means you can collect all the children of an arc, or the descendants, the ancestors, the siblings, if there’s an implied order on them. So it gives you a lot of functionality to be able to manipulate, or to navigate through those graphs and pull data out and then do stuff with it.
Federico Tomassetti:
Yeah. It seems a problem that is not trivial because it’s so abstract that provide a language, that make it easy. I think it’s challenging. Yeah.
Campbell Pryde:
Yeah. And this is an area which is really going to explode probably in the next five years. Particularly with things like AI is using these networks, and a lot more data is being described in this way. Particularly, and I know people talk about Web 2.0 which came, and how can you navigate this stuff? But I think with things like AI is bringing a lot of the stuff to the fore, because they kind of work the same way. And then building rich models, XBRL is kind of that, make them talk about things like RDF and using it, there’s no real data available. But XBRL actually has a lot of data available now, which you can use and XULE is just a tool which allows you to navigate all of that stuff.
Federico Tomassetti:
Yeah, it’s also data that is a very high quality. Well, also thank you to your quality checks, but I think this makes a difference with a lot of data that is available out there in other formats that is not really well polished or refined, so. Good, good. Well, I would like to thank you a lot for your time and sharing your experience with us. I think it’s been very interesting also, because the problems you’re working on at such a scale where they are really worthwhile relevant problems. So it was really a pleasure. Thank you very much for your time.
Campbell Pryde:
And thank you Federico. Thank you for helping us out so much. I really appreciate all the stuff that you guys have done. And if anyone has any other questions based on this interview, you can go to our website, and we’re more than happy to talk to you or anyone about this.
Federico Tomassetti:
Good, good. And we will add all the links in the article. Yeah. Thank you. Have a nice day.
Campbell Pryde:
You too. Thanks. Thank you.
Federico Tomassetti:
Bye.
