Justin Deoliveira wrote:
>> Sounds great! Question is there any chance of combining the xml
>> plugins? Ie GML2 and Filter 1.0 kind of work togther, same deal for GML3
>> and Filter 1.1... perhaps we could reduce the number of plugins by
>> grouping compatible plugins together?
>>
> I am n
>>
> Sounds great! Question is there any chance of combining the xml
> plugins? Ie GML2 and Filter 1.0 kind of work togther, same deal for GML3
> and Filter 1.1... perhaps we could reduce the number of plugins by
> grouping compatible plugins together?
I am not sure others will agree. And i
Justin Deoliveira wrote:
> Jody Garnett wrote:
>
>
>> Question - these things are "plugins" for xml-xsd are they not? Well
>> everything other then "engine"...
>>
> They are not plugins. Not in the same sense as datastores anyways.
> Clients have to depend on the mo
Jody Garnett wrote:
>>>
> Question - these things are "plugins" for xml-xsd are they not? Well
> everything other then "engine"...
They are not plugins. Not in the same sense as datastores anyways.
Clients have to depend on the modules directly.
>
> Should we not have:
> - modules/library/x
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> I would like to change this structure to the following:
>>
>> unsupported/
>> xml-xsd/
>>engine/
>>gml2/
>>gml3/
>>filter/
>>sld/
>>
>> I figure that this will be a necessary step when it moves to supp
Justin Deoliveira ha scritto:
> Hi all,
>
> I dont think anyone will have any objections but I thought I would bring
> it up anyways. Currently the unsupported xml stuff is structured like:
>
> unsupported/
> xml-xsd/
> xml-gml2/
> xml-gml3/
> xml-filter/
> xml-sld/
>
> I wo
Hi all,
I dont think anyone will have any objections but I thought I would bring
it up anyways. Currently the unsupported xml stuff is structured like:
unsupported/
xml-xsd/
xml-gml2/
xml-gml3/
xml-filter/
xml-sld/
I would like to change this structure to the following:
uns
