Discussion:
[OpenLayers-Users] WMS GetCapabilities parser
(too old to reply)
Andreas Hocevar
2010-09-01 22:24:06 UTC
Permalink
Hey Bart-
1) a response can have multiple typeNames, so now I've changed the output for attributes to have a multi-dimensional array i.e. attributes[layer][attribute].name. Is this okay with you guys since this changes your interface?
The problem I see with your change that the new structure does not know
the typeName. So you would either have to make attributes a hash keyed
by typeName, or stick with attributes as it was and add a typeName
property to each attribute.

I think the latter is easier to handle in most use cases, but I have no
strong preference.
2) for type should we remove the namespace or not? Now we can have xsd:string, xs:string and string e.g.
Since what we are parsing here is an XML Schema, we could in principle
also have complex types that are defined in the schema. So I would say
the type should be without namespace prefix, but there should be an
additional property called typeNS or something, containing the namespace
URI of the type.
3) should we not also parse minOcccurs and nillable attributes? A WFS client needs to know this in order to know if the element can be ommitted or not. But maybe this quite specific and only used by Ionic and we should leave this for a future version?
I think this is useful information and can be added without much effort.
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000521.html
Good catch. GeoServer does not return a version at all, so the best
thing to do would be to set defaultVersion to "0.1" and rename the
versioned parser v1_0.js to v0_1.js.
Btw, feel free to edit the bartvde/owsformats sandbox. I hope we can quickly put this into a patch for OL trunk
I'd say let's also hear Tim's opinion (and others can chime in as well
if they feel like), but from what I see making these final changes is an
effort of 1/2 hour for each of us if we share the work. I'd like to take
on the type namespace part.
http://trac.openlayers.org/browser/sandbox/bartvde/owsformats
Thanks for your efforts!
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
bartvde at osgis.nl ()
2010-09-01 22:24:06 UTC
Permalink
Hi Andreas,

I'll look into solving issue 1, good catch. I agree on 2) and 3).

With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?

Best regards,
Bart
Post by Andreas Hocevar
Hey Bart-
1) a response can have multiple typeNames, so now I've changed the
output for attributes to have a multi-dimensional array i.e.
attributes[layer][attribute].name. Is this okay with you guys since this
changes your interface?
The problem I see with your change that the new structure does not know
the typeName. So you would either have to make attributes a hash keyed
by typeName, or stick with attributes as it was and add a typeName
property to each attribute.
I think the latter is easier to handle in most use cases, but I have no
strong preference.
2) for type should we remove the namespace or not? Now we can have
xsd:string, xs:string and string e.g.
Since what we are parsing here is an XML Schema, we could in principle
also have complex types that are defined in the schema. So I would say
the type should be without namespace prefix, but there should be an
additional property called typeNS or something, containing the namespace
URI of the type.
3) should we not also parse minOcccurs and nillable attributes? A WFS
client needs to know this in order to know if the element can be
ommitted or not. But maybe this quite specific and only used by Ionic
and we should leave this for a future version?
I think this is useful information and can be added without much effort.
4) I've removed using the version of the root node, since this is not
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000521.html
Good catch. GeoServer does not return a version at all, so the best
thing to do would be to set defaultVersion to "0.1" and rename the
versioned parser v1_0.js to v0_1.js.
Btw, feel free to edit the bartvde/owsformats sandbox. I hope we can
quickly put this into a patch for OL trunk
I'd say let's also hear Tim's opinion (and others can chime in as well
if they feel like), but from what I see making these final changes is an
effort of 1/2 hour for each of us if we share the work. I'd like to take
on the type namespace part.
http://trac.openlayers.org/browser/sandbox/bartvde/owsformats
Thanks for your efforts!
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev
Andreas Hocevar
2010-09-01 22:24:06 UTC
Permalink
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.

Regards,
Andreas.
Post by bartvde at osgis.nl ()
Best regards,
Bart
Post by Andreas Hocevar
Hey Bart-
1) a response can have multiple typeNames, so now I've changed the
output for attributes to have a multi-dimensional array i.e.
attributes[layer][attribute].name. Is this okay with you guys since this
changes your interface?
The problem I see with your change that the new structure does not know
the typeName. So you would either have to make attributes a hash keyed
by typeName, or stick with attributes as it was and add a typeName
property to each attribute.
I think the latter is easier to handle in most use cases, but I have no
strong preference.
2) for type should we remove the namespace or not? Now we can have
xsd:string, xs:string and string e.g.
Since what we are parsing here is an XML Schema, we could in principle
also have complex types that are defined in the schema. So I would say
the type should be without namespace prefix, but there should be an
additional property called typeNS or something, containing the namespace
URI of the type.
3) should we not also parse minOcccurs and nillable attributes? A WFS
client needs to know this in order to know if the element can be
ommitted or not. But maybe this quite specific and only used by Ionic
and we should leave this for a future version?
I think this is useful information and can be added without much effort.
4) I've removed using the version of the root node, since this is not
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000521.html
Good catch. GeoServer does not return a version at all, so the best
thing to do would be to set defaultVersion to "0.1" and rename the
versioned parser v1_0.js to v0_1.js.
Btw, feel free to edit the bartvde/owsformats sandbox. I hope we can
quickly put this into a patch for OL trunk
I'd say let's also hear Tim's opinion (and others can chime in as well
if they feel like), but from what I see making these final changes is an
effort of 1/2 hour for each of us if we share the work. I'd like to take
on the type namespace part.
http://trac.openlayers.org/browser/sandbox/bartvde/owsformats
Thanks for your efforts!
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
bartvde at osgis.nl ()
2010-09-01 22:24:06 UTC
Permalink
Hi Andreas,

just to clarify, the 0.1 is not the version of XML Schema (which now is at
1.1 indeed), it's the version of the GML application schema used by the
WFS service. With Mapserver and Geoserver this always auto-generated, but
there are WFS products out there which can use a static xsd file, and if
the datamodel is updated, a new xsd is generated with preferably a higher
version.

Best regards,
Bart
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Regards,
Andreas.
Post by bartvde at osgis.nl ()
Best regards,
Bart
Post by Andreas Hocevar
Hey Bart-
1) a response can have multiple typeNames, so now I've changed the
output for attributes to have a multi-dimensional array i.e.
attributes[layer][attribute].name. Is this okay with you guys since this
changes your interface?
The problem I see with your change that the new structure does not know
the typeName. So you would either have to make attributes a hash keyed
by typeName, or stick with attributes as it was and add a typeName
property to each attribute.
I think the latter is easier to handle in most use cases, but I have no
strong preference.
2) for type should we remove the namespace or not? Now we can have
xsd:string, xs:string and string e.g.
Since what we are parsing here is an XML Schema, we could in principle
also have complex types that are defined in the schema. So I would say
the type should be without namespace prefix, but there should be an
additional property called typeNS or something, containing the namespace
URI of the type.
3) should we not also parse minOcccurs and nillable attributes? A WFS
client needs to know this in order to know if the element can be
ommitted or not. But maybe this quite specific and only used by Ionic
and we should leave this for a future version?
I think this is useful information and can be added without much effort.
4) I've removed using the version of the root node, since this is not
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000521.html
Good catch. GeoServer does not return a version at all, so the best
thing to do would be to set defaultVersion to "0.1" and rename the
versioned parser v1_0.js to v0_1.js.
Btw, feel free to edit the bartvde/owsformats sandbox. I hope we can
quickly put this into a patch for OL trunk
I'd say let's also hear Tim's opinion (and others can chime in as well
if they feel like), but from what I see making these final changes is an
effort of 1/2 hour for each of us if we share the work. I'd like to take
on the type namespace part.
http://trac.openlayers.org/browser/sandbox/bartvde/owsformats
Thanks for your efforts!
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
Andreas Hocevar
2010-09-01 22:24:06 UTC
Permalink
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Wait. The "0.1" that Mapserver returns for the version is indeed the
version of the XML Schema. So in fact we should have a
Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for the
WFSDescribeFeatureType parser.

At least that is how it should be done. For now, your proposal does
definitely make sense, at least until we find some other use case where
we need to parse XML Schema. This can easily be refactored later without
changing the API.

Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
bartvde at osgis.nl ()
2010-09-01 22:24:06 UTC
Permalink
Hi Andreas,

if Mapserver is using the version attribute for the XMLSchema version,
that's a mistake, see:

http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000523.html

Best regards,
Bart
Post by Andreas Hocevar
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Wait. The "0.1" that Mapserver returns for the version is indeed the
version of the XML Schema. So in fact we should have a
Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for the
WFSDescribeFeatureType parser.
At least that is how it should be done. For now, your proposal does
definitely make sense, at least until we find some other use case where
we need to parse XML Schema. This can easily be refactored later without
changing the API.
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
Andreas Hocevar
2010-09-01 22:24:06 UTC
Permalink
Post by bartvde at osgis.nl ()
if Mapserver is using the version attribute for the XMLSchema version,
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000523.html
That's interesting. Interesting because this does not seem to be part of
the WFS spec, and because it is different than with other OGC services.
And if it is true, we will definitely put no further effort into version
detection and get rid of Format.WFSDescribeFeatureType.v1_0 in favor of
having just one unversioned parser.

Does this make sense?

Regards,
Andreas.
Post by bartvde at osgis.nl ()
Post by Andreas Hocevar
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Wait. The "0.1" that Mapserver returns for the version is indeed the
version of the XML Schema. So in fact we should have a
Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for the
WFSDescribeFeatureType parser.
At least that is how it should be done. For now, your proposal does
definitely make sense, at least until we find some other use case where
we need to parse XML Schema. This can easily be refactored later without
changing the API.
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
bartvde at osgis.nl ()
2010-09-01 22:24:06 UTC
Permalink
Hi Andreas,

that makes sense, and was exactly what I was thinking as well this
morning. Remove the versioned parser and have an unversioned parser. I'll
make some changes today in the sandbox to reflect this.

Best regards,
Bart
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
if Mapserver is using the version attribute for the XMLSchema version,
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000523.html
That's interesting. Interesting because this does not seem to be part of
the WFS spec, and because it is different than with other OGC services.
And if it is true, we will definitely put no further effort into version
detection and get rid of Format.WFSDescribeFeatureType.v1_0 in favor of
having just one unversioned parser.
Does this make sense?
Regards,
Andreas.
Post by bartvde at osgis.nl ()
Post by Andreas Hocevar
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Wait. The "0.1" that Mapserver returns for the version is indeed the
version of the XML Schema. So in fact we should have a
Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for the
WFSDescribeFeatureType parser.
At least that is how it should be done. For now, your proposal does
definitely make sense, at least until we find some other use case where
we need to parse XML Schema. This can easily be refactored later without
changing the API.
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
Andreas Hocevar
2010-09-01 22:24:09 UTC
Permalink
Hi,

after a long break, I revisited this format class in Bart's sandbox,
rewrote it using the new XML parsing style for better performance, and
made the output more verbose and closer to the schema (e.g. we now use
targetNamespace instead of featureNS). The new version also supports
restricted types.

Ticket with patch: http://trac.openlayers.org/ticket/1202

Regards,
Andreas.
Post by bartvde at osgis.nl ()
Hi Andreas,
that makes sense, and was exactly what I was thinking as well this
morning. Remove the versioned parser and have an unversioned parser. I'll
make some changes today in the sandbox to reflect this.
Best regards,
Bart
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
if Mapserver is using the version attribute for the XMLSchema version,
http://lists.opengeospatial.org/pipermail/wfs-dev/2008-December/000523.html
That's interesting. Interesting because this does not seem to be part of
the WFS spec, and because it is different than with other OGC services.
And if it is true, we will definitely put no further effort into version
detection and get rid of Format.WFSDescribeFeatureType.v1_0 in favor of
having just one unversioned parser.
Does this make sense?
Regards,
Andreas.
Post by bartvde at osgis.nl ()
Post by Andreas Hocevar
Post by Andreas Hocevar
Post by bartvde at osgis.nl ()
With 4) I don't really agree, since 0.1 is a very arbitrary used version
by Mapserver. Since it is the version of the application schema, it should
not be used at all IMHO. I think the person calling the parser is
responsible for putting the version in the constructor, since he also knew
the version when doing the DescribeFeatureType request (version is a URL
parameter there). I've used this approach in the test cases. What do you
think?
Good point. You are right that this 0.1 version is arbitrary, because
XML Schema is currently at version 1.1 or something. For now, I really
think you are right that parsing the version attribute is an
inappropriate way to determine what we have to parse here. So yes,
omitting the version detection seems ok for now. If we find WFS
implementations out there that return a completely different schema, we
will have to cope with this in a different way.
Wait. The "0.1" that Mapserver returns for the version is indeed the
version of the XML Schema. So in fact we should have a
Format.Schema.v0_1 and Format.Schema.v1_0 parser and mix this in for the
WFSDescribeFeatureType parser.
At least that is how it should be done. For now, your proposal does
definitely make sense, at least until we find some other use case where
we need to parse XML Schema. This can easily be refactored later without
changing the API.
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
Loading...