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

[Richard Martell <rmartell@galdosinc.com>]

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.