Base types v3.3 and v3.2 schemas
|Status:||Proposed||Start date:||12 Nov 2014|
|Priority:||Urgent||Due date:||30 Nov 2014|
|Assignee:||Michael Lutz||% Done:|
During the development of the Annex II+III data specifications and schemas, a new version 3.3 of the Base Types schema (http://inspire.ec.europa.eu/schemas/base/) was accidentally created (due to an accidental change in the UML data model). The updated schema is missing the <member> element inside the <SpatialDataSet> element (because this was removed in the accidental updated of the UML model).
The Annex II+III data models are referring to this new (wrong) version of the base types schema
<import namespace="http://inspire.ec.europa.eu/schemas/base/3.3" schemaLocation="http://inspire.ec.europa.eu/schemas/base/3.3/BaseTypes.xsd"/>
while the Annex I schemas refer to the old version:
<import namespace="urn:x-inspire:specification:gmlas:BaseTypes:3.2" schemaLocation="http://inspire.ec.europa.eu/schemas/base/3.2/BaseTypes.xsd"/>
To fix this, we see the following options:
- Deprecate (or remove?) v3.3 of the Base Types schema and change the references in all Annex II+III schemas back to v3.2.
- Publish a bugfix version 3.3.1 of the Base Types schema that is effectively equal to the v3.2 (i.e. includes again the the <member> element). In this option, there would also be the question, whether the namespace should be
Option (1) would have the drawback of having to change (publish bugfix versions of) all the Annex II+III schemas, but would be clear that nothing changed in the Base Types schema.
Option (2) would require fewer changes in schemas (only the Annex I schemas, which will be updated anyway for making them compatible with the recent IR updates), but would pretend that something changed in the Base Types schema, while really it has remained unchanged.
We would have a preference for option (2) with
http://inspire.ec.europa.eu/schemas/base/3.3 as the namespace.
#1 Updated by Peter Parslow over 5 years ago
In my opinion, option 1 is better. Preferring option 2 seems to prioritise short term over long term. Option 1 leaves a cleaner set of information; with option 2 we would permanently have base 3.3.1 the same as base 3.2, which would frequently raise the question 'why' & require explanation. Over time that may become more expensive than putting the evidence in now to eradicate all traces and 'pretend' that this mistake never occurred.
Of course, if it had been possible for people to use the current base 3.3, then I would advise the opposite.
However, when I discussed this with Clemens we agreed that in the light of D2.7 v3.3 Recommendation 11, SpatialDataSet should be deprecated, as wfs:FeatureCollection is now to be used instead. Michael Lutz & Robin Smith were aware of that (by email) in September 2014 (I had hoped it would come formally via my MS POC too).
#2 Updated by Michael Lutz over 5 years ago
- Description updated (diff)
- Assignee changed from Chris Schubert to Michael Lutz
I'm struggling a bit with what to do with the base types schema in the light of the Annex I schema updates and to reflect the recommendation in the Encoding Guidelines v3.4:
7.4 Encoding of spatial object collections
Spatial data is exchanged as a collection of spatial objects.
Recommendation 5: For the download of a pre-defined (part of a) spatial data set via the operations specified in part A of the download service implementing rule and for the download of spatial objects via the operations specified in part B of the download service implementing rule, the same object collection container should be used for the same type of representation.
EXAMPLE For GML data, the WFS 2.0 FeatureCollection element is used.
As Clemens and Peter point out, the SpatialDataSet class should be deprecated in the schema for this reason.
I'm leaning to the following procedure:
- Deprecate v3.3(.0) of the Base Types schema
- Create a bug fix version 3.3.1 of the Base Types schemas in which the SpatialDataSet class is deprecated (rather than removed as currently in v3.3.0)
- Change the references in all Annex II+III v3.x schemas back to v3.2 (in bug fix versions 3.x.1)
- Use 3.3.1 as a reference for the newly created schemas 4.0
Please let me know if this is a useful way forward or if you have other suggestions.
Thanks & best regards,
#3 Updated by Simon Templer over 5 years ago
I have a question on the deprecation of SpatialDataSet - what are the reasons for that? Is it only to have a uniform representation from download services no matter if based on Atom or WFS? (and we cannot change the container for the WFS results)
I understood the SpatialDataSet as a means to retain information about its identity and origin (INSPIRE ID and metadata) even when it is shared independently of network services (or after it was downloaded to a file). Description of SpatialDataSet in the schema:
The type SpatialDataSet is offered as a pre-defined type for spatial data sets. INSPIRE application schemas may specify their own spatial data set types. It specifies three properties: an external object identifier, a container for metadata (may be void), and an association to zero or more spatial objects.
Semantically the WFS FeatureCollection is a query result. For WFS 2.0 the attributes numberMatched and numberReturned are mandatory - what would be the adequate usage for those if used for pre-defined data sets? Should for instance, if a data set is partitioned into multiple files numberMatched hold the number of overall features in the data set, while numberReturned holds the number of features in the file?
If SpatialDataSet is deprecated this should be clearly marked and stated also in the schema documentation to avoid confusion.