[wfs-dev] summary of changes from wfs 1.0 to 1.1?

[Clemens Portele]

To add to what Peter said: During a discussion of aliases for feature type
names, I did raise the issue that WFS 1.1 only specifies that "specifying
more than one typename [in the typeName attribute of wfs:Query] indicates
that a join operation is being performed." It does not specify how exactly
such a join would work in the context of XML and/or the General Feature
Model nor how the result schema would be constructed. The further discussion
showed that all this is not clear from the paragraph contained in WFS 1.1.
The conclusion of the discussion was that it should either be fixed by
specifying how "join" is actually supposed to work in the WFS context
(similar to the topics raised in the OWS-4 discussion pointed out by Steven)
or the small paragraph menioning it should de removed until a more detailled
change proposal for the inclusion of joins would be available. As Peter
mentioned, there was a informal vote / straw poll in the Joint OGC RWG / ISO
PT on this but I do not remember seeing the results.

Clemens

> -----Original Message-----
> From:
> wfs-dev-bounces+portele=interactive-instruments.de at opengeospatial.org
> [mailto:wfs-dev-bounces+portele=interactive-instruments.de at ope
> ngeospatia
> l.org]On Behalf Of Panagiotis (Peter) A. Vretanos
> Sent: Monday, October 16, 2006 10:39 PM
> To: John Herring
> Cc: 'Chris Holmes'; geoserver-devel at lists.sourceforge.net;
> wfs-dev at opengeospatial.org; 'Ian Turton'
> Subject: Re: [wfs-dev] summary of changes from wfs 1.0 to 1.1?
>
>
> John Herring wrote:
> > Peter,
> > 	Better yet, what is the OGC document number of the
> > change request that removed join?  That should explain it.
> >
> > Regards,
> > John
> >
>
> As far as I know there was no formal change proposal.  Clemens raised
> the issue of dynmaically encoding joins through the WFS interface and
> after discussion within the RWG, it was put to a vote and everyone
> present decided to remove joins.
>
> Please note that I am not the RWG chair.  I am simply reporting what
> happened.
>
> >
> > Peter,
> > 	Could you be more specific about why you are
> > thinking of dropping joins.
> >
>
> Because it is unclear how two joined features would be
> composed in GML
> to generate a response and what the GML schema would even look like.
>
> > 	A query without a join could not even do basic
> > spatial query, so how is join-less WFS to do anything of
> > value spatially other than some sort of "get features (with
> > some attribute and type restrictions) within this (constant)
> > widow?" Without a join, one of two spatial parameters of a
> > spatial operation will have to be a constant.
> >
>
> Even though joins cannot be encoded in the WFS interface this
> does not
> mean that you cannot support joins (spatial or otherwise).  It simply
> means that you must create a view of the joined features (and a GML
> schema to encode it XML) and offer that view through the WFS.
>
> I other words you cannot "dynamically" request that a WFS join two
> features; the join must be pre-specified in a GML application
> schema and
> that schema can be offered through the WFS.
>
> > 	That is "mostly useless" as query. That cannot be
> > what you mean.
> >
>
> I wouldn't say "mostly useless".  Most other OGC services (WMS, WCS,
> etc.) only support the type of query that you describe and they do
> useful work.  Don't they? :)
>
> Ciao.
>
> --
> Panagiotis (Peter) A. Vretanos          CubeWerx Inc.
> Big Kahuna (Senior Database Developer)  http://www.cubewerx.com
> Tel. 416-701-1985 Fax. 416-701-9870     pvretano at cubewerx.com
>
> "If you want to make an apple pie from scratch, you must first
>   create the universe." -- Carl Sagan
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev