Clarify what "extension" to the core mean ...

[pvretano]

Do we need to clarify what "extension to core" means in the core document? During Tb14 there was a question about how someone know whether an extension is "official" OGC extension versus some "adhoc" extension. Perhaps labeling extensions that don't go through the SWG as "community" extensions would clarify the issue and maybe we need some language in the core about that. This is a situation similar to what is happening in geopackage which have a number of extensions coming on line that are not necessarily extensions that have gone through the OGC review and vote process.

[ogcscotts]

Perhaps we follow (in part) what happens with CityGML: they have the concept of "Application Domain Extensions" (ADEs) which allow users to extend functionality as they see fit. Those ADEs are ungoverned, but if anyone wants to submit one to OGC to be passed as an official extension (which becomes a standard), then that can happen. I think it would be best to roadmap the extensions planned to be created by OGC and make that information quite clear. Also be explicit that extensions cannot change the core. Further, OGC started a registry of "community" ADEs for CityGML, but that effort has not been well maintained; with new registry capabilities now in OGC, we could track such extensions for any standard.

[cportele]

In the OGC Specification Model "extension" is defined as "requirements class which has a direct dependency on another requirements class". I.e., a requirements class where the WFS 3.0 Core requirements class is a listed as a direct dependency.

If OGC endorses it, it will either be an OGC standard, OGC best practice or OGC community standard. If it is OGC endorsed, I assume that we will eventually list it on http://www.opengeospatial.org/standards/wfs.

For extensions specified by a community or a vendor/product, it would indeed by good to have a registry somewhere, where all extensions can be submitted and found with some metadata. That registry should then also include the OGC approved extensions.

Whether we need to add something in the spec, I don't know. The concepts are already specified normatively in the OGC Specification Model. I think this is more for the Guide.

[cmheazel]

We should have a short, clear, and normative definition of extension and the process for governing extensions. However, I don't think this should be part of the Core. Perhaps the WFS 3.0 standard should be a collection of documents including a normative governance spec.

[cportele]

OGC already has a short, clear and normative definition of "extension", see my comment above.

Regarding governance, if it is an OGC document, the usual rules for the document type apply. For example, the CRS extension could be Part 2 of the WFS 3.0 series and the normal rules for OGC standards would apply.

For non-OGC extensions the publisher determines the governance rules.

[lieberjosh]

I agree. Extension definition should not be WFS-specific. Extension conformance classes should further constrain existing classes (Type 1) or define properties not constrained in existing classes (Type 2) such that implementations of the extension are also conformant with what is being extended.

That does leave the question, though, whether there is practical backwards compatibility, i.e. can a “core” client actually do something useful with an “extension” server. This sort of documentation is more specific to each standard and extension, and perhaps belongs in an extension registry.

[cmheazel]

I'm not sure I would call the Mod-Spec short and clear, but it is normative. So I think we have this issue covered. A registry of extensions would be useful. Would we also use this registry to advertise draft extensions? These would be extensions which need additional community input before they are ready for prime time.

[aaime]

I think the discussion is giving too much importance/credit to the "letter of the specification". Out there in the wild the people knowing the specs by heart are few and far between, and there is a number of people interested in leveraging ambiguities to push their agenda. "Official Extension" and "Community Extension"/"Vendor Extension", if properly socialized, would create a language that people commonly use to speak about extensions, and would make them raise the question "official or vendor?" any time someone comes up saying "we have this WFS extension doing XYZW".