OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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]