[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Handling Default ValueLists
Some additional comments. Note that enumerations may in some cases really be taxonomies - i.e. values in the enumerated list might be subsequently expanded into value lists of their own. For example, we might have an initial list of incident types like: Fire Flood Explosion Earthquake And then realize that these need to be further refined ("subtyped") into say Fire |-Forest |- House Flood Explosion Earthquake Hence modeling enumerations as flat hierarchies which can then be easily extended is something to think about. See additional comments in line with your text... -----Original Message----- Hi all, Still learning and trying to get up to speed here, so take my comments with a grain of salt :) 1. The concept of a registry is good, and I can see a case being made to have a national register that defines the code tables specific to a country - e.g. the US would have one registry, New Zealand another, Canada their own, etc. Whilst there is often a lot of similarities between these, there are often small tweaks required to different countries and their terminology. [RTL] This is one of the advantages - one can easily deploy different registries for different environments - but they can also share content. We do this now in the petroleum sector. 2. I guess that it is up to the software to cache registries/code tables offline in case there is no connectivity during an emergency? I don't think we should be expecting realtime validation against a remote registry/code list during an emergency. [RTL] I think there are a variety of strategies. We have client tools that do validation and which cache code lists as you say. In terms of how it could be provided, I'd actually support making it available via as many means as possible. It shouldn't be limited to just XML, for example. It might be very useful for developers to also have code tables available as JSON via a REST interface, so that web applications can directly access the code tables as a web service (even if just internally between multiple web apps running on the same server). [RTL] Our registry can deliver content in a variety of encodings – but based on a common internal representation. We have a transformation utility that applies a transformation, the latter associated to the content (and there can be many such associations). The HTML output in the example provided previously was generated in this fashion. JSON could just as easily be generated in the same manner. The registry can support a RESTful, POST/GET or SOAP interfaces for data requests. This is something we've been working on in Sahana Eden, and it is quite capable at publishing the same data via a variety of different formats (just by tweaking the extension on the URL). Conceivably it should be quite easy to implement a registry or code table, and have it returned via XML, JSON, CSV and any other formats desired. Implementation of a new output format is pretty simple, it just requires the creation of a new XSLT stylesheet to define the export format. So, what we may look at is a means of pulling down the authoritative online source e.g. CAP-CP in XML, and importing that to populate a local registry that can be used without having to poll on server on the internet everytime a CAP-CP message is created or read. [RTL] We suggest this be based on the OGC CSW-ebRIM standard since this supports classification schemes (enumerations), associations etc etc. Setting up a mirror should not be difficult. We can provided automated synchronization of master and slave registries. This way we can readily obtain the objective of multiple registries with partially mirrored content, supporting multiple formats etc. From our perspective, it would be great to package a list of online registries and code tables, and when a new server is activated, to go out and suck down the latest versions online (or even offline from a USB stick) and quickly setup a lot of this data for use in an application. [RTL] Ultimately we might want to have a registry of such registries – again easily done with the CSW-ebRIM – since there are metadata models already for service interfaces (other registries). That said, I can also see the case where it would be useful for an organisation to define their own registry/code table so that it fits within their own business logic - particularly if for internal use only, and the data isn't necessarily going to be used by other orgs. So again, it may come back to the software, and the software administrator may have a deployment choice to make whether they want to use external registries, or whether they want to define and host their own internally. Cheers Gavin Sahana Eden <http://eden.sahanafoundation.org/> Sahana Eden S3XRC - how we handle exports in multiple formats <http://eden.sahanafoundation.org/wiki/S3XRC> Sahana Eden S3XML On-the-fly Transformation <http://eden.sahanafoundation.org/wiki/S3XRC/S3XML/Transformation> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]