Create a list of OGC standards that are "not yet Web-friendly enough" plus rationale for each

[6a6d74]

During the Fort Collins F2F meeting we agreed to create a list of OGC standards that are "not yet Web-friendly enough" that we could provide to the OGC Architecture Board (AOB) for their consideration; including a rationale for each.

Target was for the July OAB.

[lvdbrink]

Compiling list now in https://github.com/w3c/sdw/blob/gh-pages/roadmap/non-webby-ogc-standards.md

[lvdbrink]

The list of non webby OGC standards is ready for group review!

@lieberjosh when do you think we can schedule this as an OGC Architecture Board topic? This would give us a review deadline. (I completely missed July...)

[cportele]

I just had a look. Some thoughts:

Observations and Measurements GML encoding
Rationale: Superseded by SSN.

I do not think this is accurate. SSN is targeted for the Semantic Web community and does not supersede O&M GML, which targets developers that prefer XML.

I also do not see how O&M GML can be classified as non-webby as it is consistent with the architecture of the Web (in fact, one could argue more than many JSON encodings as it supports links!).

O&M GML may be complex and verbose, but the same is true for SSN, isn't it? I have the feeling that the current approach mixes at least two aspects: whether or not a standard is consistent with the web architecture and whether or not a standard is considered too complex for most non-GI-experts. Maybe this should be separated? WMS is not webby, but has been used by many non-experts. O&M GML is webby, but probably too complex for most non-experts.

Then there is the 3rd aspect that the trend is in favour of JSON compared to XML. I think the point there could be made that XML-based standard may be webby, but do not meet the expectation of many Web developers. This should not imply that the existing standards should be changed, but it could be pointed out to consider new standards / variants that support JSON and not XML (both for data and other API payloads).

By the way, O&M is scheduled for a revision which should make it consistent with the SDW WG work on SOSA/SSN. In addition there is ongoing work in OGC on a simpler GML and JSON encoding for O&M: https://github.com/opengeospatial/omsf-profile

IndoorGML / CityGML
Rationale: GML encoding is not web friendly.

See above.

In addition, is the point that the application schemas are too rich too be handled by non-expert Web developers?

[ogcscotts]

I agree with Clemens. Perhaps this group should be split into two categories:

1. those standards which are not webby enough (i.e., need modernization to fully support current web architectures) and
2. those standards which could have web-friendly implementations (i.e., encodings more friendly to developers, such as JSON, or profiles that simplify the content for non-expert use cases).

Many of the OGC W*S standards fit in the first category, many of the traditional encoding standards in the second (e.g., CityGML >> CityJSON, Moving Features CSV >> Moving Features JSON Best Practices).

It sounds counter-intuitive that "Web Something Service" is less "webby" than a standard without "web" in the name, but I cannot think of a better way to describe the problem than with "webby."

[prushforth]

re: "Webby": The architecture of the Web demands that a URL be embedded in a hypertext medium a.k.a. a link. As far as WMS, WFS and WMTS go, we have defined a format (MapML) which is that medium, to the extent possible without demanding changes to those services. This is consistent with Web design principles. Web architecture was designed for browsers, incidentally. This is also an area where the conversation about REST has completely failed us, to the point where it's actively harmful to understanding to mention it. Consider it not mentioned here.

We hope to get MapML onto the development roadmap for browsers, not only by thinking about it and contributing, but equally importantly by coming together around the specification as our community's offering to the Web at large.

when do you think we can schedule this as an OGC Architecture Board topic?

Having the OGC AB ponder this question might be good. In the meantime, consider this an invitation to join the Maps for HTML Community Group as a way of representing this coming together. Also, please contribute / check us out!

Footnotes:

I often hear people say that XML is not Web-friendly, so why would you define another *ML? The answer is another question, which is: "Who is the (developer) you are trying to reach with the format?" For us the answer is: the same people who HTML is designed to reach, i.e. people who make web pages, who range in skill from absolute beginners, such as children learning about the Web, to the highly-skilled and knowledgeable developers who define and maintain browser engines, and everyone in between. Also, not unimportantly, for Web crawlers, which benefit from declarative formats by not having to execute programs to understand the content.

Now some of the cruft that comes along with XML, especially namespaces, we don't need and neither do the people we're trying to reach, so we didn't use them. That is one step in the direction of simplicity. Further, we are trying to not re-invent a whole vocabulary, but to seamlessly extend the HTML vocabulary, in a way that minimally fits the requirements. That is another design decision in the direction of simplicity, but it is a tightrope.

[ogcscotts]

@prushforth We can get a discussion of MapML to the OGC Architecture Board (OAB) at your convenience. The OAB is happy to review work as it evolves. Just let me (Scott Simmons) know, and I will request an agenda slot.

[lvdbrink]

I agree with Clemens. Perhaps this group should be split into two categories:

• those standards which are not webby enough (i.e., need modernization to fully support current web architectures) and
• those standards which could have web-friendly implementations (i.e., encodings more friendly to developers, such as JSON, or profiles that simplify the content for non-expert use cases).

I like this idea. The second category could be about 'web-developer-friendly implementations'.

[lvdbrink]

Clemens said:

• Observations and Measurements GML encoding
  Rationale: Superseded by SSN.

I do not think this is accurate. SSN is targeted for the Semantic Web community and does not supersede O&M GML, which targets developers that prefer XML.

I took the statement about it being superseded from the f2f minutes and my personal notes, but looking again I see that we were talking about OM Lite there (which I didn't put on the roadmap, as it's not an official standard). I'll amend this, also in the roadmap itself.

At the Fort Collins f2f we talked about the criteria for putting things on this list. We didn't take the time then to discuss them in depth, but we mentioned a few and I tried to capture this at the top of the list. I think some of your statements can help us refine them:
Criteria in general for ending up on this list:

• It needs modernization to fully support current web architectures. For example, it is using http only as a transport protocol. In contrast, standards which use http as an interface are considered 'Webby'. ( Scott's addition in italics)
• It's been replaced with something that's designed to be more web friendly. > We can probably drop this as a criterium. When a standard has been replaced by something more webby, it must not have been very webby in the first place so it should already qualify for the list based on that. I will remove this one as a criterium.
• It's too complicated to be used in a Web context. Based on Clemens' text we can amend this to It's considered too complex for most non-GI-experts.
• New criterium based on Clemens' and Scotts suggestion: It is not web-developer-friendly, i.e. does not meet the expectation of many Web developers.

Do you think we need to add some explaining text to the criteria (based on the notes in this issue I could do that). It would just be for the benefit of the OAB at this point.

[jabhay]

I think that looks good @lvdbrink.

@cportele's comment about the distinction between consistency with web architecture vs friendliness to the broader web developer is incredibly important - and warrants representative input from that audience. I'd be interested in bouncing some ideas on how to facilitate that input. @ogcscotts: might OGC consider tapping into some broad developer plugfests with say a challenge followed up by a quick feedback survey? I'm sure you've already considered this, if not done it already?

[lvdbrink]

I did a rewrite of the criteria and made some other adjustments; any more comments?

[lvdbrink]

Having received no more comments, I think this list is ready to send off to the OGC Architecture Board (OAB).

[lvdbrink]

The list is now on the agenda for the OGC Architecture board meeting of nov 27th '18.