|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| | == SDMX-JSON == | | == SDMX-JSON == |
| − | | + | Removed because they were draft. |
| − | | + | |
| − | '''Meeting minutes of the 1st meeting'''
| + | |
| − | | + | |
| − | '''Date:''' 2012-06-07/2012-06-08 Time (from - until): 09:00 – 17:30 CEST
| + | |
| − | | + | |
| − | '''Keeper of Minutes:''' Xavier Sosnovsky
| + | |
| − | | + | |
| − | '''Location''': FAO
| + | |
| − | | + | |
| − | '''Attendees''': Sami Airo (Bank of Finland), Jens Dossé (OECD), Alistair Hamilton (Australian Bureau of Statistics), Susie (Australian Bureau of Statistics), Juan Muñoz López (INEGI), Jay Devlin (Statistics New Zealand), Matt Nelson (Metadata Technology), Olav ten Bosch (Statistics Netherlands), Spyros Liapis (Agilis SA),Matt Nelson, Erik van Ingen (FAO), Dario (FAO), Xavier Sosnovsky (ECB)
| + | |
| − | | + | |
| − | '''Absents''': Ole Sørensen (Danmarks Nationalbank), Bengt-Åke Lindblad (Eurostat), Xavier Martín Badosa (Statistical Institute of Catalonia), Arofan Gregory (Metadata Technology)
| + | |
| − | | + | |
| − |
| + | |
| − | | + | |
| − | == 1. Results ==
| + | |
| − | | + | |
| − | 1. The group started from the following assessment:
| + | |
| − | | + | |
| − | a) More and more web services nowadays are RESTful
| + | |
| − | | + | |
| − | b) The majority of RESTful web services offer exchange formats other than XML. Some 20% don’t even offer XML at all.
| + | |
| − | | + | |
| − | c) JSON is a widespread format for RESTful web services.
| + | |
| − | | + | |
| − | => This led to the conclusion that it would help implementers if SDMX could offer other syntaxes than XML for web services interactions in a RESTful scenario and JSON was identified as the more appropriate candidate for addition.
| + | |
| − | | + | |
| − | | + | |
| − | 2. In addition to this, the current SDMX web services specifications can be perceived as too complex for many web developers:
| + | |
| − | | + | |
| − | a) XML is often seen as too complex
| + | |
| − | | + | |
| − | b) The SDMX information model can be seen as too complex
| + | |
| − | | + | |
| − | c) Resolution of references (for example, from code id to code name) could ease the work of implementers
| + | |
| − | | + | |
| − | | + | |
| − | 3. From these starting points, the group agreed that having an implementation of the SDMX information model in JSON could bring the following benefits:
| + | |
| − | | + | |
| − | a) Increased utilisation of SDMX web services
| + | |
| − | | + | |
| − | b) Easier data extraction
| + | |
| − | | + | |
| − | c) Reducing developers burden
| + | |
| − | | + | |
| − | d) Improved accessibility (reaching broader audience)
| + | |
| − | | + | |
| − | => Further supporting the needs of the open data community
| + | |
| − | Typical “target” applications would be visualisation tools, potentially running on mobile devices.
| + | |
| − | | + | |
| − | | + | |
| − | 4. The group then identified the following requirements for the work to be done:
| + | |
| − | | + | |
| − | a) Based on SDMX (information model, RESTful API, etc)
| + | |
| − | | + | |
| − | b) Optimised for the web and mobile devices (JavaScript, lightweight, RESTful principles)
| + | |
| − | | + | |
| − | c) Simple, terse & solid JSON
| + | |
| − | | + | |
| − | d) Works with both JSON parsing and streaming
| + | |
| − | | + | |
| − | e) Should keep open the possibility to validate a message
| + | |
| − | | + | |
| − | The issue of whether the structural information should be packaged in the data message has not been resolved yet.
| + | |
| − | | + | |
| − | | + | |
| − | 5. It quickly became apparent that there might be two (potentially conflicting) use cases:
| + | |
| − | * One with a focus on data visualisation, where the JSON message should be as simple as possible.
| + | |
| − | * One with a focus on dissemination, for example, using the RESTful API but request JSON instead of XML, where the richness of the SDMX information model need to be preserved.
| + | |
| − | | + | |
| − | | + | |
| − | '''The group agreed to first focus on the use case of data visualisation.'''
| + | |
| − | | + | |
| − | | + | |
| − | 6. To support the use case of data visualisation (both for data retrieval, i.e. prepackaged queries, and data discovery, i.e. dynamic queries), the following artefacts need to be supported:
| + | |
| − | * Priority 1: DataSet, Series and Observations (not sure about groups yet)
| + | |
| − | * Priority 2: CategoryScheme, Categorisation, Dataflow, Constraint, DSD, ConceptScheme, Codelist, HierarchicalCodelist and ProvisionAgreement
| + | |
| − | * Priority 3: AgencyScheme, DataProviderScheme, MSD, Metadataflow
| + | |
| − | It was highlighted that the fact that an artefact needs to be supported does not necessarily means it needs to be returned in the JSON message.
| + | |
| − | | + | |
| − | | + | |
| − | 7. The group also agreed that fixed metadata fields (not mandatory) might ease the work of implementers (a fixed field for example, to indicate what the title of the series to be displayed is). It was agreed to start identifying relevant concepts from the list of SDMX cross-domain concepts.
| + | |
| − | | + | |
| − | | + | |
| − | 8. Last but not least, the group identified the following next steps:
| + | |
| − | * Initial setup on github (Sami, Xavier)
| + | |
| − | * Review the COG (Al, Susie, Xavier)
| + | |
| − | * Review the JSON message design options (Matt, Sami, Dario, Juan, Spyros, Xavier)
| + | |
| − | * Virtual meetings on a monthly basis (starting on the12th of July, 14:00 CEST)
| + | |
