Toby,
I draw a deep breath here and sigh. OK - let's state this in as massively large letters as possible "THINK SIMPLE".
The past ten years are littered with well meaning projects that have been a bonanza for high paid consultants morphing otherwise simple business scenarios into wildly complex XML mechanisms that only the few can grok. The list is large and growing: XBRL, OAGi BODs, UBL, and NIEM are prime examples. The main culprit of this is W3C XSD schema syntax and its plethora of complexity and mechanisms that lead to non-deterministic definitions.
So - the lesson learned is that interoperability is driven by simplicity and the ability to share coherent and consistent exchange definitions between participants.
This is further reinforced by realizing that in large distributed process systems the trick to success is NOT to attempt to define every possible permutation - but instead to define the APIs around the interchange points - ensuring that each part can plug predictably into the next - and respond in a reliable way.
Another pitfall introduced by Berners-Lee and the W3C is the need to send the entire semantics along with the interchange because they are averse of a registry driven architecture - instead wanting no points of failure - everything to be localized. The result of this is schema and the XML transactions contain huge amounts of markup bloat. This is the opposite of what is needed in terms of simple, terse and precise interchanges. Their business model is documents that have to survive 30 years and be parseable. Most business information exchanges need only a couple of years, 5 years tops of readability.
Fortunately there are the means to control all this at hand. Separating the exchanges from the definitions; simplifying the on-the-wire content; making process control simple; defining clear, simple and reliable communications.
Not everyone is onboard however. Too often I see hardware vendors salivating over the vast amounts of equipment needed to drive the exchange standards they are anticipating. They get just slightly miffed when folks point out that better design can reduce all that by a factor 10x.
I'd like to see us focusing on SIMPLE and ELEGANT as a prime objective. And remember just because it is simple does not mean it is limited. Quite the contrary. Simple can be powerful and comprehensive too.
So before we get sucked down into a technology vortex - I'd prefer to stay at a high level and work out what the key operational characteristics and go to market capabilities need to be. Defining those is much more productive IMHO - and avoids the trap of basing everything around schemas - even if OASIS thinks that what every good TC should be doing (they are learning - but slowly!).
-------- Original Message --------
Subject: RE: [smartgrid-discuss] OpenADR, SmartGrid Information Models
and a Proposal
From: "Considine, Toby (Campus Services IT)" <Toby.Considine@unc.edu>
Date: Fri, December 19, 2008 5:52 am
To: "'Benjamin A. Rolfe'" <ben@blindcreek.com>, "i2g_interop@nist.gov"
<i2g_interop@nist.gov>, "smartgrid-discuss@lists.oasis-open.org"
<smartgrid-discuss@lists.oasis-open.org>
http://wwww3.org/2001/XMLSchema">
+1
If I understand you, Ben, you challenge us with market design, and doing so in such a way that the market rules do not constrain the solution.
That is the correct charge. It requires that we keep interactions on the surface, and avoid deep process interactions…
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 |
|
blog: www.NewDaedalus.com |