[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
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]