Energy Market Information Exchange - XML message models, non-XML formats, DFDL

[Bob Schloss <rschloss@us.ibm.com>]

Hi Ed, Brian and Toby,

      I have been lurking
on the smartgrid-interest list from OASIS, as I do not expect to become
a formal member of any of these TCs (my IBM Research colleague Jane Snowdon
has joined one; and my IBM Research colleague Ron Ambrosio has been involved
in various angles of the NIST Roadmap).  But by way of self-introduction,
I should say that I have long involvement in web scale evolvable data sharing
technologies: I co-chaired the World Wide Web Consortium working group
that product Resource Description Framework, I manage the central group
at IBM Research working on core XML standards, processing libraries, and
interpreters and compilers for XPath, XSLT, XQuery etc.  (We also
do a lot of work with RDF query, Linked Data and OWL reasoners).  And
I hope to help adapt our general purpose technologies to the needs of distributed
operations of Smart Grids over the next 2+ years.  

     I want to comment
on the idea that if we have a defintion of an XML message format for some
information to be transmitted to another program or device, we still can
have flexibility in both the transport, and in the format of the bits during
the transmission.  

     There is a working
group that defined a Data Format Description Language, which basically
allows a correspondance to be expressed between a binary, columnar or compressed
textual format, and the "logical" XML message structure that
it corresponds to.  While some people might just use this as the formula
for a physical rewriting by mapping -- concretely materializing the XML
starting with the compressed format, one of my colleagues, Kristoffer Rose,
demonstrated that certain kinds of XPath access code can use the "XML
view" of the "compressed message" without necessarily doing
the entire conversion -- something that is valuable if parts of the compressed
messages are never accessed by some intermediatory logic -- for example,
something which tests just a few fields and then routes the message one
way or another.  

     If you are interested
in more of Kris' thoughts, papers, examples..., see http://domino.research.ibm.com/comm/research_projects.nsf/pages/virtualxml.index.html
.

     People pronounce
the acronym for DFDL like the name of the flower "daffodil".

      If anyone on this
list wants more info on DFDL, use your search engine to find the full specs,
or look at a quick overview that Jim Myers of PNNL produced:
http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.dfdl-wg/docman.root.current/doc5426

           
           Thanks,
           
            Bob

Senior Technical Staff Member and Manager
IBM Thomas J Watson Research Center
Hawthorne, New York, USA

Edward Koch <ed@akuacom.com>

08/12/2009 10:59 AM

To	Marty Burns <burnsmarty@aol.com>, "'Brian Frank'" <brian@skyfoundry.com>, "'Considine, Toby (Campus Services IT)'" <Toby.Considine@unc.edu>
cc	"'William Cox'" <wtcox@coxsoftwarearchitects.com>, "smartgrid-interest@lists.oasis-open.org" <smartgrid-interest@lists.oasis-open.org>, "'Toby Considine'" <Toby.Considine@gmail.com>
Subject	RE: [smartgrid-interest] Energy Market Information Exchange Charter -         supporters wanted; ready for submission to create Technical Committee

Brian,
 
The questions you raise concerning
REST pertain to the description of the “service” that conveys the information
and not necessarily to the information that is conveyed through that service.
 For example in the current OpenADR spec there is am XML definition
for the the so called EventState.  Furthermore there are specifications
for how that EventState is conveyed using REST, SOAP, and BACnet web services.
 Each of those differ in how the service for conveying the EventState
is specified even though the information that is transported through each
service is the same.
 
 
-ed koch

---

From: Marty Burns [mailto:burnsmarty@aol.com]
Sent: Wednesday, August 12, 2009 6:36 AM
To: 'Brian Frank'; 'Considine, Toby (Campus Services IT)'
Cc: 'William Cox'; smartgrid-interest@lists.oasis-open.org; 'Toby Considine'
Subject: RE: [smartgrid-interest] Energy Market Information Exchange
Charter - supporters wanted; ready for submission to create Technical Committee
 
Brian,
 
Pricing information will
need to be conveyed by several protocols – from Web Services to compact
binary SCADA. As such, we have to separate the information model from its
conveyance. OASIS, I believe, will help to define the information model
and at least one Web Services means. However, I think visibility of the
need to convey the same semantics in other syntax’s should help guide
the effort.
 
I am a fan of the “REST”
ful type of modeling, as I understand it currently in a very limited way,
in that it exposes rich information models with generic basic services
to accomplish action.
 
Cheers,
Marty
 
Dr. Martin J. Burns
President
Hypertek, Inc.
14624 Country Creek Lane,
North Potomac, MD 20878
P - 1(301)315-9101
C - 1(301)257-9101
 
 
 
From: Brian Frank [mailto:brian@skyfoundry.com]
Sent: Wednesday, August 12, 2009 9:26 AM
To: Considine, Toby (Campus Services IT)
Cc: William Cox; smartgrid-interest@lists.oasis-open.org; Toby Considine
Subject: Re: [smartgrid-interest] Energy Market Information Exchange
Charter - supporters wanted; ready for submission to create Technical Committee
 
My understanding as Bill said that
this specification is about *modeling* - nothing to do with transactions
or protocols.
 
If that is true, then the two most
important aspects of modeling are:
  - type system
  - naming system
 
The type system is how we define
data structures and contractual definitions.  I will assume that the
"type system" will be XML Schema since it is the safe choice
(despite being quite poor as a modeling type system).
 
The naming system is how we identify
entities and reference them.  Any sophisticated model requires referencing
things.  Independent of the protocols used, RESTful means that we
leverage URIs for naming. 
 
Both modeling and naming are areas
which oBIX has really nailed.  But it doesn't sound like oBIX is being
considered for the model - which is fine and to be expected.  But
both the type system and naming system still matter a great deal, especially
how they will interact with the overall system.
 
 
On Wed, Aug 12, 2009 at 8:59 AM,
Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu>
wrote:

Restful interactions have their place. As APIs at a distance, they are clean and predictable. As part of transactional systems and open bidding markets, one needs the rest of the WS Transaction infrastructure. As part of a massively distributed delayed environment that may involve long running workflows, one may need a multi-document messaging based format.

 

Zooming in on REST is a little like zooming in on UDP, only a couple layers up. There are times when RESTful connections are exactly what one needs. There are times when they are not.

 

tc

---

"A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift

---

Toby Considine Chair, OASIS oBIX TC Facilities Technology Office University of North Carolina Chapel Hill, NC

Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com

 

 

From: Brian Frank [mailto:brian@skyfoundry.com]
Sent: Wednesday, August 12, 2009 8:42 AM
To: William Cox

Cc: smartgrid-interest@lists.oasis-open.org; Toby Considine
Subject: Re: [smartgrid-interest] Energy Market Information Exchange Charter - supporters wanted; ready for submission to create Technical Committee

 
 
Energy Market Information Exchange is an XML vocabulary to express price and characteristics, so the means of communicating is not part of the charter.

 

I can see how that is nice in theory, but I don't understand how that works in practice.  At the very least any sophisticated modeling requires naming things.  And naming things typically implies a way to reference those named things.

 

So I guess my question is - will the model be RESTful in that "things" are named and referenced with URIs?