Nlets Representatives have been hearing about XML Standardization since 2014, when the Nlets Board of Directors resolved to sunset the legacy text format, replacing it with standardized XML. Despite hearing about it for years, we know that many in the Nlets community are still unfamiliar with what, exactly, XML Standardization is and why it’s such a big deal.

Let’s start at the beginning - What is XML? XML stands for eXtensible Markup Language. If you don’t already know what XML is, all you really need to know is that it’s a format in which you can send your data that labels each of the individual pieces of information in “tags” - in a way that computers and programming languages can universally understand. It’s relatively easy for a human to read too, (although if you aren’t a programmer, you’ll never need to).

For example, <Animal>Hippopotamus</Animal> shows the data “Hippopotamus” being labeled as an Animal using XML tags. Easy peasy.

The next logical question is – Why? We know what XML is, but why is it helpful and why does the Nlets Board of Directors want all of the states to use it? If we are looking at one set of data in both free-text and XML, the benefit isn’t immediately obvious:

The examples above are simple in nature but are still a good representation of the differences between a free-text and XML format. If you read the free-text example on the left, it’s easy to understand. In fact, if you’re just seeing these two in a blog post, it may seem like the XML doesn’t really add much benefit. Let’s look at another set of examples:

This example shows the exact same data as the first example. It’s still not difficult to understand, but the free text is a bit different from the first example. Notice also, that the XML versions are the same as each other.

This may be a good place to point out the importance of the discriminator, “standardized”. As you can see in the XML examples above, each piece of information about the driver is in its own XML tag. That is where all of the value of XML Standardization comes in, when it is standardized, everybody is doing it the same way, and so if you want to know the driver’s status, you can ask for the value of the <Status> tag – regardless of the state that sent the driver response.

The most important reason for the XML Standardization mandate is the roadside officer. On the roadside, the time it might take them to comb through an unfamiliar format that is full of unfamiliar codes could be significant and costly. Presenting information to the officer in a format that is familiar to them, regardless of the format of the source data, helps them to do their job more efficiently and effectively. Our world and our data have become more complex than they were when Nlets began and there are a myriad of pieces of information that can be misconstrued without a standard format.

A common misconception early on in this project was that if your state was sending XML at all, you were done. However, if a state is just wrapping up the plain text response in one giant XML tag, (imagine putting just one XML tag around the whole text response on the left above), then it’s not all that helpful in terms of understandability. So, remember, even if a state started wrapping responses in XML back in 2004, that doesn’t mean it has already completed XML implementation - It could mean that they are a bit closer, though! Likewise, Nlets has now standardized virtually all our response types. Having implemented standardized criminal history and DMV queries is a tremendous start, but would not quite put a state over the finish line for this project.

As we previously mentioned, if you’re not a programmer, then you will never need to read XML itself. XML is easily turned into text or other formats with “Stylesheets”. Stylesheets are a critical part of the power of XML and standards and why XML is such a great solution for a community like ours.

Nlets provides a stylesheet for each message type that will turn the XML into a more presentable format. While stylesheets are helpful, every state is different and has their own needs. Some use the Nlets-provided stylesheet, but others tailor them it to meet their own needs. If a state wants every other state’s response to look just like their existing in-state response, a stylesheet can do that! If they want to use different labels that their users are more familiar with, a stylesheet can do that! Order data differently, add a caveat or highlight important information? It can do that. Perhaps they want a different format to show up for desktop users and a more concise format for mobile user. That’s possible too!

Beyond stylesheets, other programming can add even more functionality: plotting addresses on a map, pre-filling or automatically running follow-up queries, and more. With standardized XML, almost anything that you might want to do to highlight or use a piece of data is possible because it’s very easy for a computer program to find and understand the data.

To fully harness the potential of standardized XML, our community needs everybody to start sending it. There is no doubt that this is a big endeavor. And as with any big endeavor, it can feel intimidating to get started. If you know that you need to upgrade your state to standardized XML and are unsure where to start, your first phone call should probably be to your switch owner, whether that is one of our amazing vendors or an in-house team. They can help to guide you on what, if any, work they need to do. If a state is already sending XML, there may not be much work for the switch owner to do. The switch requirements to handle standardized XML are, in general:

• Understand and use the XML header information, like ORIs and message key

• Transport the XML that your repositories create

• Apply stylesheets to inbound XML to make the data human readable again

The most difficult part of preparing to send standardized XML is getting the data out of each of your repositories in a standardized format, since this is where all the variation is between states. The main problem that states face is that most repositories output a text response that’s human readable, which means states need to work with their repository to get them to output a standardized response. To do so, there are several options. The repository can output the Nlets standardized XML (the easiest approach) or they can use some other standardized format that can be converted into the Nlets standardized XML. Some repositories may be easier to work with than you’d expect; they may already have a way to return XML or already be sending XML that is just being transformed into text before the data is sent out to Nlets. In those cases, it is often easier to convert that into the Nlets standardized XML format.

There you go – that’s Nlets XML Standardization in a nutshell! If you have any other questions on XML, you can check out our XML FAQ here or email Kate Silhol at ksilhol@nlets.org. Remember that our Brodie Assistance Fund (BAF) Committee is continuing to prioritize this type of project if you need funding assistance.