Complete marketing tool set for efficiency and renewable energy pros

Home Performance XML (HPXML): What It Means. Professional content

Comment Share

By Tom Harrison - November 11th, 2010

Home Performance XMLRecently, the Building Performance Institute (BPI) announced the first version of something called Home Performance XML.  We think it has the potential to significantly benefit the energy efficiency industry, and we think BPI is the right organization to lead the charge.

It’s not entirely clear to everyone why this is a good thing, or even if it’s a good thing, and how it will help.  And let’s be honest, it’s not entirely clear what it is.

So I read about it, read the specification, and talked to several of the folks who were part of bringing it together.  My purpose is to explain what HPXML is, isn’t, what it could be and why it should matter to you.  The main audience is the people in the field who are collecting and reporting data, either during an energy audit, or when implementing efficiency improvements.

In short: it’s less paperwork.

What HPXML Is

More Than Just The Numbers

When you have completed a blower-door test, for example, you have a lot of data.  Some of it is stored in your computer by the software that runs the test.  Some of it you have to enter manually.  But it’s all data about a test, run on a specific property, on a given date, and so on.  

There are lots of blower doors made by different companies, having different versions of software to run and record the test data.  But they are all getting at pretty much the same thing.  And that same thing is only part of what may be needed.

If that software was able to export its data in HPXML, other software that also knew about HPXML could utilize that blower door test data for something else -- maybe to fill out the form required by the local utility to get a rebate.  Less paperwork.

The XML in HPXML stands for “extensible markup language”.  Well, that was easy, so moving on ... What?  Oh, sorry.

Markup Language and XML

"Markup language" is a way for computer software to share information.  In addition to the actual data, markup language helps you describe what that data is.  Let’s say you wanted to send an address to another computer, you might use XML that looked like this:

<address>
    <name>Energy Circle</name>
    <street>12 Main Street</street>
    <city>South Freeport</city>
    <state>ME</state>
    <zip>04078</zip>
</address>

In the bad old days, if you had an address in a spreadsheet, you might export it to a CSV file (“comma separated values”) that looked like:

Energy Circle,12 Main Street,South Freeport,ME,04078

A computer can suck up that CSV data, but only if it knows:

  1. What each field contains
  2. What order they appear
  3. What format the data is in

Markup language is a way to describe what type and format of data to expect, and what the relationships are between each chunk of data and how the data is named.

XML adds the all-important “X”, which means “extensible”.  If someone decided that an address should also include another field <country>USA</country>, they could add that field, and any program that worked with the original XML would still work.

Another important aspect of XML is that it has a twin brother called XSD which can be used to describe what the fields are, what they are allowed to contain, and a bunch of other stuff.  For example, you could say that <zip> should contain 5 digits, and then later, remember that zip+4 might contain 5 digits, a dash and another 4, but that the additional digits are optional.

Key Fact: HPXML is not intended to be a complete or final representation of all Home Performance data -- on the contrary, it is a small set that will be extended.

So HPXML is a specification for how data about Home Performance should be represented, named and organized.  If your software is collecting data now, it could be extended to allow the parts of the data covered by this spec to create a record in the HPXML format.  Presumably software that knows how to support this data format is more flexible.

What HPXML Is Not

HPXML is not a complete specification that defines everything there is to be defined relating to home performance.  It is a relatively small subset of the extent of data that you could imagine.  This decision was absolutely intentional, and is the right place to start, as we see it.

HPXML is not a “lock in” standard -- it’s not a play by a single company to control the market.  Anyone thinking this is a possibility would have a good reason to do so -- standards, whether in software or not, have been used as a point of control frequently in the past.

But several things about HPXML are done in a way that should set these fears to rest.  Most important, this is a standard that has been promoted and managed by BPI, and not any one company.  It has been a collaborate effort, and many of the stakeholders who could benefit from such a standard were invited, and contributed to its creation.  HPXML is an open, extensible standard.

HPXML is also not an “all or nothing” standard.  If the software you use collects some of the data specified, but not all, that’s fine.  If the software you use collects and presents data in one unit (e.g. Bars instead of Pascals) that’s not a problem -- a simple conversion is possible.  But more important, when there’s an option for how to present information, there’s clear guidance about which way is preferred.

XPHML is also not software -- it doesn’t “do” anything on its own, other than provide a clear, precise option that anyone is welcome to use as a format for collecting data.

What HPXML Can Be

HPXML is just a data standard now, but if the building performance and energy efficiency industry accepts, adopts, and demands it some important benefits arise.

For one: less paperwork.  With a standardized data format, it is straightforward to present the collected data in any number of different ways.  Rather than filling out forms again and again, if the utilities, agencies, and other programs coordinating incentives adopt and accept the standard, the form is mostly filled out already.

Software collecting and using the data can much more easily and readily work together.  You can make important business infrastructure decisions with confidence that they will not leave you stranded on an island of incompatible data.

Because measurement standards, names, units and other details are already worked out, there is less opportunity for confusion.  Consumers have a solid benchmark of their property, and contractors have a clear and stable target to aim for.

Importantly, there have been numerous discussions about how “low end” contractors with little training or actual experience are undercutting the value offered by certified professionals.  You know the value of your BPI and other certifications, but customers may not -- when it becomes required to have the details of building performance metrics presented in a complete and standard format, the charlatans will have a much harder time of it.

In general, anything that can reduce the “friction” between the various moving parts of building performance will make it easier to demonstrate the overall value of making changes.


Comments

Too bad it's called HPXML. That makes it kind of hard to use JSON instead of XML, which would be: * more concise * easier to read (human) * easier to generate * easier to parse Posted by mshook on Nov 12, 2010 2:18pm

@mshook -- thank for your comment, but let's keep the main idea: the important thing is that it's a standard.  

I am not a huge fan of XML, but after a number of years have found all the libraries I need to parse and generate and figured them out.  Certain aspects (notably XPATH, which I hate) are always a pain.  But I think XML is a better format for this kind of use.  Just my opinion -- a lot of this is a matter of what your "religion" is, I think.

JSON and XML are equally expressive (that is, they capture relationship, type and name, and can be validated), but JSON is more popular these days because it's more friendly to JavaScript and CSS implementations where it's most commonly used as the "X" in AJAX, and you have to admit, AJAX sounds a lot better than AJAJ :-)

There's no reason the standard couldn't be presented in a JSON view -- same information, different presentation.  I suspect there are XML <=> JSON libraries around.  I do think it's a matter of mostly what you're used to in terms of readability -- I looked at the JSON examples comparing to XML, and I wasn't particularly convinced that I prefer one to the other: http://www.json.org/example.html

In any case, the key thing is that we have the start of a standard way to represent Home Performance data, and ain't nothin' stopin' nobody from creating HPJSON as long as it represents the same data, names, types and relationships!

Tom

Posted by Tom Harrison on Nov 12, 2010 4:21pm

"JSON is more popular these days because it's more friendly to JavaScript and CSS implementations"

Are you suggesting there's a language out there in which JSON is *not* more friendly than XML?

"I do think it's a matter of mostly what you're used to in terms of readability"

And with JSON exploding in popularity, especially over XML, it's clear that JSON will soon be the dominant data exchange format.

My dad finds it hard to read SMS messages because they're so short but I don't think he'd define a new data exchange protocol based on fountain pens and cursive. :-)

Posted by Anonymous on Aug 4, 2014 5:33pm
> but let's keep the main idea: the important thing is that it's a standard. Agreed. But.... I put in my word for JSON over XML whenever the task is to represent data rather than markup text. In the benefits I mention, replace 'easier' with 'less energy'. It may not be much in the case of HPXML, but if every application that transmitted data (not text markup) as XML used JSON instead maybe we could shut down one rack of servers in each data center. Mayhaps one day I'll figure out how to quantify the savings. Posted by mshook on Nov 12, 2010 5:53pm

instead maybe we could shut down one rack of servers in each data center.

Agreed!

(But we're all about quantifying here at Energy Circle, so talk to the guys at CO2Stats.com who are in the business of quantifying lifecycle energy costs per compute cycle and let us know when you have a number.  Until then, we can agree that a nice to have would be: JSON is an alternative view structure.  Great programming environments like Ruby on Rails make this a part of their DNA.  But I digress.)

Posted by Tom Harrison on Nov 12, 2010 8:11pm
If you want to kill this effort look at what they did to HR-XML. http://www.hr-xml.org/ It was started as a standard and now it's a "Consortium". I recommend defining a basic standard, keeping is simple and flexible. Set up a wiki that describes the intent of the standard and how to extend it. Then walk away... While I am personally in favor of a standard what often happens is that old school companies want lock-in to their proprietary standard, making it difficult for clients to move to another organization. I think you'll see this with big utilities. I suppose I'll be very surprised to see my local power company share their data; no my data; in an open standard format. Good luck to this effort. Posted by chrisjx on Nov 17, 2010 1:45am
Chrisjx, I hope they do share. I think it'll be baby steps, but eventually everybody's energy consumption will be as transparent as their property taxes. Once that happens it will be amazing how quickly we reduce our resi load. Posted by tedkidd on Nov 23, 2011 3:11pm

Ah, standards. They are good. But they take time to come to fruition.

Two years and counting...

Posted by Tom Harrison Jr on Jun 16, 2013 4:09pm

Yes. Excruciatingly slow when you look back on it, but we are getting there. Here's a more recent update on some of the developments at the last ACI

Posted by Peter Troast on Jun 17, 2013 7:08am

I am a fan of 'open source' the proprietary guys have their place especially when they develop highly specialized software that performs great.

However, if we use the standards and 'Standard' means just that, everyone uses it as a protocol. If the utilities will share energy usage then It might as well be 'open source' there are enough layers to provide encryption as we need it to protect certain data and just 'redact' it to protect the innocent, ha ha. But data for multifamily in certain regions by square footage would help a great deal. Multifamily, will need more information specifically about building data, and if we keep it to usable building data and zip codes we could probably get cooperation for a standard to share data. Just keeping the specific data to organize the projects within the company and creating specific identifiers for each company then we could make this work for the utilities.

Posted by BIG Rob on Jul 11, 2014 8:47pm

Add comment

The content of this field is kept private and will not be shown publicly.