[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [spec comments] Richard Martell on version 2.6 specs
Richard Martell wrote: >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. > > +1 on suggested change. I think it makes good sense. > > > >>>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 :-) > > I would say it is non-normative at present and suggest we keep it that way for now. > > > >>>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>. > > That would be fabulous! >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). > > This is good to know. The implementation I work on (freebXML Registry) uses PostgreSQL. > > > >>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. > > > > Thats ounds great. Looking forward to reading these proposals. Thanks. -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]