Re: [regrep] [spec comments] Richard Martell on version 2.6 specs

["David RR Webber" <david@drrw.info>]

Did we not review the paper presented by Eliot Christian on supporting the
unified ISO query mechanism?

That was certainly posted to the eGov TC, if not also the Registry.

DW

----- Original Message ----- 
From: "Richard Martell" <rmartell@galdosinc.com>
To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
Cc: <regrep@lists.oasis-open.org>
Sent: Wednesday, August 25, 2004 6:27 PM
Subject: Re: [regrep] [spec comments] Richard Martell on version 2.6 specs


> Farrukh Najmi wrote:
> > I think you sum it up well. ExtrinsicObject without repository item is
> > heavily used
> > as a "poor man's metadata record" that can be user defined. Lets us
> > leave this issue
> > with no change.
> >
>
>
> One minor change would be called for here, I think: removing the default
> value for ExtrinsicObject.mimeType.
> i.e.,
> <attribute name="mimeType" type="tns:LongName" use="optional "/>
>
> If no value is specified, then no repository item exists. If a
> value is specified, this is the content-type of the repository item
> corresponding to ExtrinsicObject.id. This would appear to be the
> only way to signal the absence of a repository item.
>
>
> >> Just curious--under the ISO umbrella is the UML likely to become
> >> normative? We've found this to be the case as OGC specifications are
> >> "promoted" to TC 211.
> >>
> >>
> > I am a big fan of UML but I am not sure what you mean by making it
> > normative.
> > How would that impact our specs? Suggest no change here.
> >
>
>
> Normative as opposed to "inspirational" UML ;-) If this were the case,
> then mappings to other type description languages like XML Schema
> would have to be explicit and consistent. I understand this isn't the
> case now, and perhaps ISO/TC 154 is more lenient than TC 211 :-)
>
>
> >> Of course, geometry objects by themselves aren't very useful without
> >> support for spatial queries. Adding support for this would probably
> >> require an extension to the ebRS filter query grammar; happily, the OGC
> >> has already defined an XML syntax for spatial operators that could
> >> probably be incorporated without too much fuss (and ISO 19125-2 defines
> >> an SQL syntax). Anyway, a topic for future discussion if this seems a
> >> reasonable course of action.
> >>
> >>
> > My personal view is that the RS Filter Query is unwieldy and difficult
> > to maintain
> > as RIM changes. I would like to hold the line on it and replace it with
> > something like
> > XQuery in version 4. In my own apps I tend to use the optional SQL Query
> > exclusively which is
> > much more easier to use.
> >
> > If you think there is value to extending RIM for spatial queries and
> > Geometry (I think so)
> > then would it be possible for you to provide a rim.xsd patch based on
> > the version at:
> >
> >
http://cvs.sourceforge.net/viewcvs.py/ebxmlrr/ebxmlrr-spec/misc/3.0/schema/rim.xsd?rev=1.10&view=log
> >
> >
> > with the suggested changes and adequate comments. A universal diff
> > format patch would be ideal. See:
> >
> > http://ebxmlrr.sourceforge.net/3.0/PatchSubmissionGuide.html#How
> >
> > on how to submit a diff -u format patch.
> >
> > Also a brief writeup on what the spatial queries might look like in SQL
> > format would complete
> > what is needed to have a good grip on what you are proposing.
> >
>
>
> We can prepare a position paper summarizing proposed enhancements. The
> relevant standard is ISO 19125:2003 ("Geographic information – Simple
> feature access"). This in turn is based on an earlier OpenGIS
> specification available here: <http://www.opengis.org/docs/99-049.pdf>.
>
> Happily, there are a number of closed- and open-source relational
> databases that provide built-in support for spatial operators as defined
> in the OGC spec (e.g., Oracle 9/10, PostgreSQL/PostGIS, MySQL 4.1, DB2).
>
>
> > Yes extension of types is currently reserved for ExtrinsicObjects.
> >
> > Based on my limited understanding I would suggest we defer the module
idea
> > for a future release as it may not be as vitally important as spatial
> > metadata / query.
> >
>
> We'll also prepare a position paper for extension modules. Happily, no
> very substantial changes are called for here--this is more about
> codifying how RIM extensions are defined, packaged, and published.
>
>
> -- 
> Richard Martell         Public PGP key: <http://www.galdosinc.com/pgp/>
> Galdos Systems, Inc.      tel: +1 604-484-2765  |  fax: +1 604-484-2755
>
> Opinions, conclusions, recommendations, and other information presented
> in this message are not given or necessarily endorsed by my employer or
> firm. If the digital signature is invalid, I did not send this message.
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>