Move XML output to extension

[cholmes]

Having XML in as a top tier option brings in unneeded complexity. It makes a lot of sense as an extension, especially for GML 3.2 compatibility and alignment with past WFS's.

Even though it is clearly optional in the core specification it requires more cognitive overhead to figure out what is needed, and how to take out all the references. Or we may also end up with API implementations that just leave some of the XML definitions in even though they don't support it.

The core spec should be as short and sweet as possible, and having XML in there makes it not as short as it could be.

[cportele]

The GML support only adds minimal additional text to the document, but I think it is important as GML is broadly used in some communities and WFS 3.0 should be for them, too. If it is preferred, we could put all encodings in extensions, but since the encoding requirements classes are all short and every implementation needs to implement at least one encoding I am not sure whether this is helpful.

I understand the concern about the XML clutter in the OpenAPI fragments. The XML support is one aspect of OpenAPI that I do not like. Maybe we should remove them from the standard fragments.

[pvretano]

Clemens, your proposal for removing the XML clutter from the OpenAPI fragments seems fine to me.

[cholmes]

Definitely +1 on removing XML from OpenAPI fragments.

And I agree that WFS 3.0 should work for communities that support WFS 3.0 - indeed they could have their own WFS 3.0 profile that mandates not only GML but also the particular feature types that conform to the domain schemas.

But I don't think all encodings should be in extension - I think we should pick one to say it is core (though not mandatory). Having a super flexible mix and match thing is nice, but leaving too much choice can hurt, especially when people aren't from the geo world and aren't invested in implementing it. I believe it is incumbent on us to make choices to help guide implementors, while also leaving them the flexibility to change things. Since the people who will want XML will find the extensions I think we should just put it there, but make the core spec feel like it's about JSON (or JSON + HTML).

Perhaps my concerns could be mitigated by a 'simple' profile that has a few of the core choices made. Indeed the sample openapi document feels decent in that regard. But right now to go from the sample to the actual spec feels like a leap, where a whole lot of choice is open.