[OSGeo-Standards] Re: How to extend OWS Context forseveralspecific cases

Cameron Shorter cameron.shorter at gmail.com
Thu Oct 25 19:22:15 EDT 2007 

Parent directory would be sufficient, but I would probably put a copy in 
each subdirectory as well.
I see the schema versions similar to a software release, which is 
conceptually a snapshot in time of the trunk version of the 
software/schema. And the trunk version of the schema would contain 4 
files (or more), schema.xml, example(s).xml CHANGES.txt LICENSE.txt

You would probably find it useful to maintain the files in subversion.
Dare I push the relationship with OGC further and ask if they have a 
subversion server available?
(There are plenty of other alternatives available if not)

Kralidis,Tom [Burlington] wrote:
> Cameron: should a CHANGES.txt file go in each revision/directory as you
> mention below?  Or should it go in the parent dir, i.e.:
>
> http://www.ogcnetwork.net/schemas/owc/CHANGES.txt
>
> ..Tom
>
>
>  
>
>   
>> -----Original Message-----
>> From: Cameron Shorter [mailto:cameron.shorter at gmail.com] 
>> Sent: 24 October, 2007 4:26 PM
>> To: Kralidis,Tom [Burlington]
>> Cc: standards at lists.osgeo.org
>> Subject: Re: [OSGeo-Standards] Re: How to extend OWS Context 
>> forseveralspecific cases
>>
>> Thanks Tom for the update.
>> Any chance you could put the changes information you list 
>> below somewhere public.
>> Eg:
>>
>> http://www.ogcnetwork.net/schemas/owc/0.2.1/CHANGES
>>
>> This is very useful for someone upgrading to a new version of 
>> the spec.
>> Typically a CHANGES file looks like:
>>
>> version 3:
>> summary of changes
>> list of changes, often a copy from an issue tracker
>>
>> version 2:
>> ...
>>
>> version 1:
>> ...
>>
>> Kralidis,Tom [Burlington] wrote:
>>     
>>> Hi,
>>>
>>> I've uploaded a version 0.2.1 of OWS Context to:
>>>
>>> http://www.ogcnetwork.net/schemas/owc/0.2.1/owsContext.xsd
>>>
>>> Changes:
>>>
>>> - allows for an extension within owc:ResourceListType
>>> - adds @id to owc:AbstractResourceType
>>> - add sld:MinScaleDenominator and sld:MaxScaleDenominator to 
>>> ows:GeneralType
>>> - adds owc:MaxFeatures to owc:FeatureTypeType
>>> - adds multiplicity to owc:ServerType, and @default to deal with 
>>> associations within an owc:AbstractResourceType
>>>
>>> If I were to analogize this with a, say, MapServer mapfile, the OWS 
>>> Context as is would be to define remote data connections.  
>>>       
>> For local 
>>     
>>> data connections, this is where I think the community-based 
>>>       
>> extension 
>>     
>>> definition would be handy:
>>>
>>> <owc:Extension>
>>>  <osgeo:LocalLayer>
>>>    <osgeo:Name>foo</osgeo:Name>
>>>    <osgeo:Data>/path/to/data.shp</osgeo:Data>
>>>    <osgeo:Type>gml:Polygon</osgeo:Type>
>>>    <osgeo:CRS>init=epsg:4326</osgeo:CRS>
>>>    <osgeo:style>
>>>     <osgeo:SLD>/path/to/style.sld</osgeo:SLD>
>>>    </osgeo:style>
>>>  </osgeo:LocalLayer>
>>> </owc:Extension>
>>>
>>> Make any sense?  I haven't worked with deegree (what did they do to 
>>> context?  Examples?) or GeoServer in awhile, but I do recall some 
>>> XML-based defs they had for configuration.
>>>
>>> Cheers
>>>
>>> ..Tom
>>>
>>>
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: standards-bounces at lists.osgeo.org 
>>>> [mailto:standards-bounces at lists.osgeo.org] On Behalf Of 
>>>>         
>> Kralidis,Tom 
>>     
>>>> [Burlington]
>>>> Sent: 24 October, 2007 7:33 AM
>>>> To: Lorenzo Becchi; Jody Garnett
>>>> Cc: standards at lists.osgeo.org
>>>> Subject: RE: [OSGeo-Standards] Re: How to extend OWS Context 
>>>> forseveralspecific cases
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>         
>>>>> -----Original Message-----
>>>>> From: standards-bounces at lists.osgeo.org 
>>>>> [mailto:standards-bounces at lists.osgeo.org] On Behalf Of
>>>>>       
>>>>>           
>>>> Lorenzo Becchi
>>>>     
>>>>         
>>>>> Sent: 23 October, 2007 7:12 PM
>>>>> To: Jody Garnett
>>>>> Cc: standards at lists.osgeo.org
>>>>> Subject: [OSGeo-Standards] Re: How to extend OWS Context for 
>>>>> severalspecific cases
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>>>> Bleck too much; set up a wiki and track new context ideas
>>>>>>         
>>>>>>             
>>>>> in the same
>>>>>       
>>>>>           
>>>>>> manner as open street maps handles new feature types. Let 
>>>>>> collaboration and composition sort out the good ideas and
>>>>>>         
>>>>>>             
>>>>> leave OSGeo
>>>>>       
>>>>>           
>>>>>> (and a process) out of it. When we feel we have something
>>>>>>         
>>>>>>             
>>>>> good kick it
>>>>>       
>>>>>           
>>>>>> over the wall to OGC (much like with the WMS tile idea).
>>>>>>         
>>>>>>             
>>>>> why should I do twice an effort to prepare a document, when
>>>>>       
>>>>>           
>>>> OGC guys
>>>>     
>>>>         
>>>>> are here in this list?
>>>>> and if we are going in two different directions while editing 
>>>>> different documents?
>>>>>
>>>>>       
>>>>>           
>>>> I don't see this as duplicate effort.
>>>>
>>>> If I understand correctly, we are looking to develop a way 
>>>>         
>> to share a 
>>     
>>>> web mapping application configuration, which includes bindings to 
>>>> data sources, and maybe other items (styling, templates, etc.) ?
>>>>
>>>> If OWS Context suppports Extensions, then the goal here 
>>>>         
>> would be to 
>>     
>>>> define an Extension grammar (in XML, GeoJSON, whatever), which is 
>>>> then applied to OWS Context.
>>>>
>>>> Having said this, I do know that OWS Context and KML are being 
>>>> discussed as a possible harmonization item, but I'm not aware of 
>>>> where that is at as far as a decision.
>>>>  
>>>>     
>>>>         
>>>>> if we don't have a Wiki to work together we can set up one or use 
>>>>> OSGeo one.
>>>>>
>>>>> process could be easy: public Wiki to mess up the 
>>>>>           
>> Context, private 
>>     
>>>>> Wiki for OGC internal documents.
>>>>>
>>>>> make sense?
>>>>>
>>>>> ciao
>>>>> Lorenzo
>>>>>
>>>>> _______________________________________________
>>>>> Standards mailing list
>>>>> Standards at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>>>
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> Standards mailing list
>>>> Standards at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>>
>>>>     
>>>>         
>>> _______________________________________________
>>> Standards mailing list
>>> Standards at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/standards
>>>
>>>   
>>>       
>> --
>> Cameron Shorter
>> Geospatial Systems Architect
>> Tel: +61 (0)2 8570 5050
>> Mob: +61 (0)419 142 254
>>
>> Think Globally, Fix Locally
>> Commercial Support for Geospatial Open Source Software 
>> http://www.lisasoft.com/LISAsoft/SupportedProducts.html
>>
>>
>>     
>
>   


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Software
http://www.lisasoft.com/LISAsoft/SupportedProducts.html

More information about the Standards mailing list