So I guess what I will do for now is create a special mime type for
GML3, which would then support app-schema. The old mime type would still
return GML2, and produce an error if it is run against app-schema data.
Cheers
Niels
On 18/11/10 04:12, Andrea Aime wrote:
On Wed, Nov 17, 2010 at 4:25
On Thu, Nov 18, 2010 at 11:23 AM, Rob Atkinson wrote:
> I think I've missed how this will break backward compatibility with
> existing deployments, making the server respect the feature type
> definition and canonical schema as defaults would leave things alone,
> but allow new implementations t
I think I've missed how this will break backward compatibility with
existing deployments, making the server respect the feature type
definition and canonical schema as defaults would leave things alone,
but allow new implementations to be richer. If old clients cant parse
new features, it still
On Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson wrote:
> App-schema allows clients to use style sheets to deal with responses.
> (Because its a known schema, a stylesheet can be published and used to
> render it. I have build clients with catalogues of stylesheets for
> each feature type - and no wa
App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We buil
On 18/11/10 04:12, Andrea Aime wrote:
> Going out with GML3 might please
> the few that root for complex features but will break all
> other clients. At the very least the choice should be per
> layer, not per server, so that the setup that try to compromise
> between complex features and common ne
The underlying problem is that for complex features, the target GML
version is determined by the target schema, which is chosen by the data
provider and not the client. For example, a GeoSciML 2.0 feature type
*must* be delivered in GML 3.1.1, while a GeoSciML 3.0 feature type
*must* be deliver
On Wed, Nov 17, 2010 at 4:25 PM, Justin Deoliveira wrote:
> Yeah, the mime type for gml output for GetFeatureInfo was not really though
> out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
> Ideally choosing the output format would follow the way other output formats
> do it
Yeah, the mime type for gml output for GetFeatureInfo was not really though
out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
Ideally choosing the output format would follow the way other output formats
do it and just use a different mime type. "text/xml; subtype=gml/2.1.2"
