context extension vs numberMatched and numberReturned from OGC API

[mzaglia]

Should I use the context extension instead of the OGC API equivalents?

[cholmes]

@mzaglia - apologies for the super slow response. We're at a weird state with these, as we're hoping the OGC adapts to our way, but their core stuff seems to be moving slowly. If you want to be fully in line with both you can implement both in the same response. Which is clearly a bit weird, but we hold hope OGC will update. You could do /search/ in STAC with STAC style and OGC API ones with their style. Sorry we don't have a better answer here.

[m-mohr]

Would this get resolved with the new conformance classes? OGC way in /collections/... and context extension in /search?

[cholmes]

I wouldn't call that fully resolved, but yes, that should make things clearer. We can add a note in 'context' about how we expect this just to be used with STAC search.

[m-mohr]

Maybe phrase it differently. It says now:

currently scoped to just the STAC Search functionality.

But it actually is scoped to be used with everything STAC specific (e.g. collection search, item search, maybe at some point other things), but not with OGC API features.

[cholmes]

But right now it's just item search, right? We don't have collection search yet or anything else. I was thinking that when a new thing come we'd add the scope there. I don't feel strongly, just felt a little more clear to say exactly what it does cover.

[m-mohr]

It's the fragment and fragments by nature should not have a scope so that they can be re-used. Currently it sounds like it can't be re-used as it's only meant to be used with Item Search. (Actually, people may decide to use this fragment in Features for backward compatibility.)

I get what you want to express though... Maybe just start with something like that:

This extension is currently scoped to just the STAC-specific functionality such as STAC Search.

[cholmes]

Cool, I'll try again - I wasn't sure exactly how to talk about fragments / extensions well.