search

ZGIS / smart-owc-geojson

Owc Context GeoJSON Encoding for Play
Apache License 2.0
1 stars 1 forks source link

OGC OWS Context GeoJSON Encoding Standard 14-055r2 ambiguities #4

Open allixender opened 7 years ago

allixender commented 7 years ago

In the latest OGC OWS Context GeoJSON Encoding Standard 14-055r2 we came across a few ambiguities that we couldn't solve for ourselves:

I am summarising those subsequently here, with the kind request to indicate the intended standard behaviour. If that is of any help, I would be glad to support the improvement of the examples in the OGC Schemas repository as well, as they are mostly still based on the former OWS-10 testbed results.

7.1.1 Class OWC:Context: specReference

specReference: <xz>.properties.links.profiles requires the Specification Reference (requirements class) identifying that this is an OWC Context document and its version. Table 1 defines the data type as an Array of links profiles (as defined in Table 10 - data type "links") where one element SHALL have the href value “http://www.opengis.net/spec/owc-geojson/1.0/req/core”

But the multiplicity defines: One (mandatory) and the GeoJSON example 7.1.1.1 shows another different picture, which is only an array of String.

"links" : {
 "profiles" : [
  "http://www.opengis.net/spec/owc-geojson/1.0/req/core"
 ],
},

We implemented links.profiles as an array of links as objects of data type links from 7.1.10, table 10 with href, type, lang, title and length. And one mandatory link object element is required that has the specified core profile url.

Is that the desired behaviour?

7.1.2 Class OWC:Resource: resourceMetadata

Secondly, we found a quirk with the <>.properties.links.via description. In 7.1.1 Class OWC:Context "contextMetadata" is an Array of links as defined in Table 10 (Zero or more), and the example shows a JSON array. all good so far. However in OWC:Resource it is "resourceMetadata" which is also a <>.properties.links.via path but explicitly called "Link object" (whereas links.data, links.previews and links.alternatives are Arrays of Link objects). But then in the column multiplicity it states "Zero or more" as with all the other link object arrays? But the example explicitly shows a single link object under the path <>.properties.links.via:

"via" : {
  "href" : "http://www.acme.com/products/algal20090123090856.xml",
  "type" : "application/xml",
  "length" : "435",
  "title" : "XML metadata file for the entry 2009-01-23 09:08:56"
}

This is confusing. What is the intended behaviour? We chose an array of link objects to mimic the other link object arrays general behaviour. Is that appropriate?

7.1.7 DataType OWC:Creator

There seems to be an exceptionally different behaviour for "7.1.1.9 creator". In OWC:Context there is only mentioned the path: <xz>.properties.creator

with a presumably wrong and irrelevant example:

"creator" : "ACME CSW Server”,

Because the abstract 7.1.7 DataType OWC:Creator is later typed into specific:

But the actual issue that I mean is that in 7.1.7 DataType OWC:Creator specifies at first a generic extension (without a JSON path, because it is abstract) - then extension for <xz>.properties.display.* in Table 9 - Definitions of owc:CreatorDisplay elements is explicitly described BUT COMPLETELY ABSENT for <xz>.properties.generator.* in Table 8 - Definitions of owc:Creator/OWC:CreatorApplication elements.

That seems either accidental or the reason is not obvious. We chose the freedom to allow for an extension in OWC:CreatorApplication the same way the extension is declared for ALL other data types. Is that ok or did you choose the description intentionally?

DataType OWC:StyleSet

https://www.w3schools.com/js/js_reserved.asp

allixender commented 6 years ago

Unfortunately the working group is not too active currently, similar issues were reported before: https://github.com/opengeospatial/owscontext/issues/3

allixender commented 6 years ago

Compare xml https://github.com/geopython/OWSLib/pull/483