Ah, maybe that is where I tend to get off the wrong foot with a lot of folks.  I am an angle bracket type person.

So, the current strategy to get everyone on the same page with cookbooks is great.  Sample code is awesome.

However, the cookbooks make an assumption about how information is stored your RA system.  So, you have a few choices: (1) retool your data warehouse to match the cookbook, (2) redesign the hooks in the cookbook to match the data warehouse, (3) beg the cookbook author(s) for another version that matches your data warehouse.  [beyond the ususal, but I don't want to use perl, python or java or it won't work on my OS]

As some may know, I have a fair bit of sub-opinions about the consequences and solutions to 1 and 2.  There is varied interpretation of the "IOOS's do no harm" statement which further buggers up the water.

A proposed direction?

We've been creating inventories of our stuff for quite some time.  This has turned into an XML file that can harvested by obsRegistry.  At this point, the obsRegistry is now a catalog of sensors/stuff.

There are now several portals/registries of services: SOS, WMS, WCS, WxS you name it. (Geo-spatial One stop, GCMD, etc).  

If we all adopted a common data protocol, preferably those recommended by "WSDE WG", we could give the obsRegistry those endpoints.  Then, the obsRegistry becomes a dual registry for services and inventory of stuff (one-stop shop/IOOS catalog).  If folks want more detailed information, then you are passed over to the appropriate data provider to get QA/QC, expanded project or sensor metadata, etc.

The endpoints include the data transport web services and the on-line browse/web application links.  Obviously, the harvester will not be able to do a thing with the on-line browse items.

But, there is more, those same protocols recommended by "WSDE WG" will allow your data to plug into the IOOS DAC facilities (NDBC, COOPS).   Please correct me if this assumption is incorrect.