Meeting notes from February 25 meeting

24 views
Skip to first unread message

Marty Burns

unread,
Feb 26, 2014, 8:13:47 AM2/26/14
to opensg-...@smartgridlistserv.org, energy...@googlegroups.com, greenbutton-dev

All,

 

On the OpenADE call today, we recognized September 2014 as a key milestone in the deployment of many Green Button Connect My Data implementations and updates. This suggests that we focus on arriving at a usable Green Button Connect My Data test specification coincident with that deployment. We have the beginnings of this specification and should be able to complete this by summer. That should be our goal.

 

We had an intriguing discussion on today’s call. Specifically, John Teeter, our Presidential Innovation Fellow (PIF) raised the issue of the structure of URIs for Green Button Connect My Data. By way of background, at the very start of Green Button during the first implementations of GBDMD, implementers felt that there needed to be some clear definition on how the links in the Green Button atom feeds were used. There are two dimensions to this issue – one that deals with what points to what, and, the second is the composition of the “pointer”.

 

The Green Button Download My Data certification tests evaluates the correctness of what points to what based on the GreenButtonAtomLinks.docx working paper on UCAIug (http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAtomLinks.docx). For the composition of the pointer, we have examples of how one might build structured URIs.

 

We noted on the call that a review of data provided by many utilities providing Green Button DMD files all were using a structured URI as follows:

 

•       <link rel="self" href="User/9b6c7063/UsagePoint/01"/>

•       <NS:link rel="self" href="/User/9b6c7063/UsagePoint/01"/>

•       <atom:link href="User/9b6c7063/UsagePoint/01" rel="self"/>

•       <link rel="self" href="User/25cd2af5c5f6f693f8f6d62852033843/UsagePoint/01" />

•       <link rel="self" href="RetailCustomer/10/UsagePoint/01"/>

•       <link href="RetailCustomer/115973279529374200002937445377/UsagePoint/0" rel="self"/>

•       <link rel="self" href="RetailCustomer/765786587/UsagePoint/01" />

•       <link rel="self" href="/User/9b6c7063/UsagePoint/01"/>

•       <atom:link href="User/9b6c7063/UsagePoint/01" rel="self"/>

•       <link rel="self" href="/User/9b6c7064/UsagePoint/01"/>

•       <atom:link href="/User/9b6c7063/UsagePoint/01" rel="self"/>

•       <link rel="self" href="/RetailCustomer/1/UsagePoint/J2753386"/>

•       <link href="/v1/User/455/UsagePoint/580" rel="self"></link>

•       <link rel="self" href="User/9b6c7063/UsagePoint/01"/>

•       <link rel="self" href="User/9b6c7063/UsagePoint/01"/>

•       <link rel="self" href="User/9e610ca8441264b3d21cad5b2a13d028/UsagePoint/01" />

•       <link href="/v1/User/12704625/UsagePoint/4218907" rel="self"></link>

•       <link href="/User/4685/UsagePoint/67" rel="self"/>

•       <link rel="self" href="User/00e308198d020442995dea12c013f77a/UsagePoint/01" />

•       <link rel="self" href="/User/1564408+15644/UsagePoint/0"/>

 

We further noted that the structure of the URI had two main parts (note the part labeled endpoint may be constant for the file and not included in each link):

•       URI ::= protocol://hostname:port/datacustodian/espi/1_1/resource/ ç resource endpoint of the server

•       /RetailCustomer/{retailCustomerId}/UsagePoint/{usagePointId}/… ç structured path to data resource

•       /User/{retailCustomerId}/UsagePoint/{usagePointId}/… ç structured path to data resource

 

The structured path to information is based on the “navigable” class structure of Green Button data – UsagePoints have MeterReadings which have IntervalBlocks, and so on.

 

On the other hand, it was discussed that URI definitions by themselves are supposed to be “opaque” on the one hand, but, REST API best practices suggest they be structured. The NAESB standard has it both ways with:

 

“Since all URIs are opaque references, there is no mandated form. However, it may be useful to organize them hierarchically, in order to define URIs for the appropriate containers (feeds), and to manage permissions.”

 

All examples in the NAESB specification are structured URIs.

 

We finally discussed some pros and cons of the various approaches and considered that there might be four possible outcomes for OpenADE to settle on:

1.    No structure, support opaqueness

2.    Optional Structure, make structured URIs an optional Function Block

3.    Required Structure, make structured URIs a requirement but allow some variability – e.g. User versus RetailCustomer

4.    Single Required Structure – defined structure based roughly on GreenButtonAtomLinks and Authorization documents

 

The consensus of those on the call was 4). However, we thought reaching out for some additional input would be desirable. The notes from the meeting can be found at:

http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/OpenADE_2014_Notes/Notes20140225.pptx

 

If we determine that 4) will be the path forward, we will do some combination of producing testable requirements for the Green Button Connect My Data test plan, and, adding some content to the NAESB REQ.21 revision that just started last week.

 

Please provide your comments and thoughts.

 

Cheers,

Marty

 

Dr. Martin J. Burns, Hypertek Inc. for NIST

Technical Champion, Green Button

p-1(301)315-9101

c-1(301)257-9101

email: ma...@hypertek.us

 

 

Teeter, John

unread,
Feb 26, 2014, 9:13:47 AM2/26/14
to energy...@googlegroups.com, opensg-...@smartgridlistserv.org, greenbutton-dev
Marty,

Thank you for capturing the discussion. Three things I would like to point out:

  1. This decision affects both Green Button Connect My Data (CMD) and Green Button Download My Data (DMD). They both must use espiDerived.xsd – right now very few organizations with deployed DMD are certifiable using espiDerived.xsd – and thus not interoperable.
  2. The OpenESPI (https://services.greenbuttondata.org/ & https://github.com/energyos) currently consumes opaque URIs and produces structured URIs. From this experience, I can say clearly that It is quite a bit more effort to consume opaque URIs within the Green Button espiDerived.xsd representation. It would have been much easier to just tokenize the URIs within the <link rel="related" … /> tags during import. 
  3. If we are going to, as a community and as an ecosystem, agree to use structured URIs, we ALL must do it. This is an ALL OR NON decision point IMHO. If any organization does not commit to supporting fully specified URIs in the Green Button <link …/> representation, the publish/subscribe, and RESTful patterns, then it will be as though no-one does, because it will require all third party parsers to, as was done in the OpenESPI code, be able to consume non-structured URIs. That means the parsers being build by GSA and EPA and Opower and Aclara and SilverSprings and SDG&E and Lucid and First Fuel etc. etc. are all going to be affected.

It is a critical time the holly grail of a uniform interoperability in the Green Button world.  We will be reaching out to each of the development organizations over the next 1 month to help you understand the issue and to reach a commitment as to the approach your organization will be taking. Note that ALL approaches to this URI issue include a commitment to support the Green Button schema as defined in espiDerived.xsd.  

I am preparing a private doodle poll where each organization within the ecosystem may indicate their commitments on this issue. The Doodle poll is a hidden/private poll. Keep in mind,  (IMHO)  the full interoperability of the Green Button ecosystem is at stake on this issue. 

We get this right, and we will have achieved the vision set forth by Aneesh Chopra!  We waffle and what could have been becomes just that ….

We can do it:) 

To re-iterate the Doodle Poll questions will be:

  1. No structure, support Opaque URIs using either HTTPS or FTPS protocols in conjunction with the espiDerived.xsd schema. Make Opaque URIs part of the CORE CMD function block.
  2.  Optional support Structured URIs using either HTTPS or FTPS protocols:  make Opaque URIs part of the CORE CMD function block,  and  structured URIs an optional Function Block in CMD Testing & Certification in conjunction with the espiDerived.xsd schema
  3. Required Structure, make structured URIs a requirement but allow some variability – e.g. User versus RetailCustomer; Thus structured URIs would be part of the CORE CMD function block in CMD Testing & Certification in conjunction with the espiDerived.xsd schema.
  4. Specific Required Structure  based on espiDerived.xsd Resource Names as described in two documents:  GreenButtonAtomLinks and Authorization document 

 (and just for the record, the EnergyOS Green Button stack is fully supporting option #4 today, but because of lack of commitment from everyone, has had to also support #1 …)

John Teeter
-----
Office: 301-975-4743 
Mobile: 301-325-7608
Presidential Innovation Fellow
Green Button for America


From: Marty Burns <ma...@hypertek.us>
Reply-To: "energy...@googlegroups.com" <energy...@googlegroups.com>
Date: Wednesday, February 26, 2014 8:13 AM
To: "opensg-...@smartgridlistserv.org" <opensg-...@smartgridlistserv.org>
Cc: "energy...@googlegroups.com" <energy...@googlegroups.com>, greenbutton-dev <greenbu...@googlegroups.com>
Subject: [ESPI] Meeting notes from February 25 meeting

All,

 

On the OpenADE call today, we recognized September 2014 as a key milestone in the deployment of many Green Button Connect My Data implementations and updates. This suggests that we focus on arriving at a usable Green Button Connect My Data test specification coincident with that deployment. We have the beginnings of this specification and should be able to complete this by summer. That should be our goal.

 

We had an intriguing discussion on today’s call. Specifically, John Teeter, our Presidential Innovation Fellow (PIF) raised the issue of the structure of URIs for Green Button Connect My Data. By way of background, at the very start of Green Button during the first implementations of GBDMD, implementers felt that there needed to be some clear definition on how the links in the Green Button atom feeds were used. There are two dimensions to this issue – one that deals with what points to what, and, the second is the composition of the “pointer”.

 

The Green Button Download My Data certification tests evaluates the correctness of what points to what based on the GreenButtonAtomLinks.docx working paper on UCAIug (http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAtomLinks.docx). For the composition of the pointer, we have examples of how one might build structured URIs.

 

We noted on the call that a review of data provided by many utilities providing Green Button DMD files all were using a structured URI as follows:

 

•       <link rel="self" href="User/9b6c7063/UsagePoint/01"/>

•       <NS:linkrel="self" href="/User/9b6c7063/UsagePoint/01"/>

•       <atom:linkhref="User/9b6c7063/UsagePoint/01" rel="self"/>

•       <link rel="self" href="User/25cd2af5c5f6f693f8f6d62852033843/UsagePoint/01" />

•       <link rel="self" href="RetailCustomer/10/UsagePoint/01"/>

•       <link href="RetailCustomer/115973279529374200002937445377/UsagePoint/0" rel="self"/>

•       <link rel="self" href="RetailCustomer/765786587/UsagePoint/01" />

•       <link rel="self" href="/User/9b6c7063/UsagePoint/01"/>

•       <atom:linkhref="User/9b6c7063/UsagePoint/01" rel="self"/>

•       <link rel="self" href="/User/9b6c7064/UsagePoint/01"/>

•       <atom:linkhref="/User/9b6c7063/UsagePoint/01" rel="self"/>

--
--
You received this message because you are subscribed to the "energyos_espi" group.
To post to this group, send email to energy...@googlegroups.com
To unsubscribe from this group, send email to: energyos_esp...@googlegroups.com
 
http://www.energyos.org/espi/
 
---
You received this message because you are subscribed to the Google Groups "energyos_espi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to energyos_esp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages