Javascript Object

[juanmav]

Hi,

I was looking for a CSW Javascript library and I only found this one. Yes, it only has one operation implemented (GetCapabilities) but I think it has a good code base to build up from it, in some days I am going to do a pull request.

I was wondering about json responses from CSW-Server, already have a pycsw server running, but the CSW standart documentation explain the only response required to by supported is "xml" so I guess "json" response has no standart constrains. Requesting the data from a CSW Server (pycsw or another implementation) with "output Format=application/json" not necessary will has standart/consistent response from server or another server (pycsw or not).

So my question is: it will be better aproach to request an standart xml response ("outputFormat=application/xml") and transform this response to json in the client side?

Doing this we also can have a better javascript object, example:

From pycsw server, to have a title from a record:

• Results.children[i].children['title'].text

With XML to client side Json generated:

• Result.records[i].title

Thanks in advance Regards JM

[tomkralidis]

Hi @juanmav

One option would be detect JSON support from GetCapabilities parsing. If the CSW supports JSON as an outputFormat, then request it, bless it as JSON and carry on. Else, request the default (application/xml).

Having said this, even if JSON is supported by various CSWs there is (currently) no consistent representation between them. So it's probably better just to deal with the XML and deal with it consistently in csw4js.

Thanks for the interest in csw4js, contributions are welcome!

[juanmav]

Hi, @tomkralidis,

I was playing a little bit around with the XML to JSON transformation and the ways to deal with it in a consistently way.

To accomplish the XML to Json I found https://github.com/highsource/jsonix it is a Javascript library which allows you to convert between XML and JSON structures with the advantage this transformations are done throwght mappins pre-defined using the XSD files (XML Schema Definition), providing a cosistently way to do this task. To generate this mappings the configuration already exist at https://github.com/highsource/ogc-schemas

A working example http://jsfiddle.net/08bdzkwz/2/

Maybe will be a good aproach make a csw4js to deal internally with XML (using jsonix as help) and expose a Javascript/JSON interface to work with plain javascript, javascript's frameworks and so on hidding the XML communication wtih the server.

Thanks in advance Regards JM

[juanmav]

@tomkralidis,

I just made changes at my fork commit: eacee996a9913c10ef69f59f1d04f6187fd93a1f, added Jsonix with CSW support (CSW_2_0_2_Full.js).

If you think it is a good path I going to polish the code and make a pull request (using requirejs)

Thanks in advance Regards JM

[tomkralidis]

@juanmav thanks for the info. I think this approach is the way to go -- nice work!

Can we not manage src/CSW_2_0_2_Full.js, and have it added by a build step or something? Like have a Grunt process which fetches/creates/etc src/CSW_2_0_2_Full.js?

Regardless, something we can work out the details later on. Looking forward to pull request -- thanks!

[highsource]

@tomkralidis I can add CSW_2_0_2_Full to ogc-schemas scripts so you could get it via NPM or Bower or Maven or whatever.

[tomkralidis]

@highsource that would be great! @juanmav does this work for you?

Where's the ogc-schemas distribution/manifest? I'm guessing other schemas like FES, GML, OWS Common are already there.

[juanmav]

@tomkralidis Yes of course! The files are at https://github.com/highsource/ogc-schemas/tree/master/scripts/lib

The last commit already has the packege.json modified:

"dependencies" :{
        "jsonix": ">=2",
        "ogc-schemas": ">=2"
    }

We only need to update the ogc-schemas registry at NPM to include the CSW_2_0_2_Full and delete this file from csw4js repository.

@highsource can you do it? I would be very grateful.

Thanks in advance Regards JM

[highsource]

Sure, could you please file an issue in ogc-schemas? To track it.

Am 17.01.2015 um 17:27 schrieb Juan Mahuel Vicente notifications@github.com:

@tomkralidis Yes of course! The files are at https://github.com/highsource/ogc-schemas/tree/master/scripts/lib

The last commit already has the packege.json modified:

"dependencies" :{ "jsonix": ">=2", "ogc-schemas": ">=2" } We only need to update the ogc-schemas registry at NPM to include the CSW_2_0_2_Full and delete this file from csw4js repository.

@highsource can you do it? I would be very grateful.

Thanks in advance Regards JM

— Reply to this email directly or view it on GitHub.

[juanmav]

@highsource, https://github.com/highsource/ogc-schemas/issues/42

[tomkralidis]

How would we envision working with the JSONIX output/JavaScript object/JSON? Does csw4js create an abstraction on top of this output, or developers using the library use the JavaScript object/JSON directly?

The latter approach means csw4js then only focuses on the CSW API per se (which is fine). At the same time I'm wondering if the bare JSONIX output is too verbose/cumbersome to expose for csw4js, then this would mean csw4js implements a simpler content model atop JSONIX

For example, consider the use case of "do a CSW GetRecords request and foreach record display the title".

Comments? What do other downstream JSONIX-based libs do?

[highsource]

I've added CSW_2_0_2_Full to scripts, released to npm. There's also a 2.0.2 tag on GitHub so it should be available via Bower as well.

Test:

https://github.com/highsource/ogc-schemas/blob/master/scripts/tests/CSW/2.0.2/CSW_2_0_2_Full.js

[highsource]

@tomkralidis Ok, now on csw4js/jsonix/ogc-schemas integration.

Jsonix only addresses XML<->JS transformation. You can cut the effor of transforming your JS payload into XML - or XML back to JS. You'll get correct types and predictable structures.

This is good and a lot but it is only a part of csw4js task (or ows4js in general). Developers would expect a CSW-oriented API with methods for GetCapabilities, DescribeRecord, GetRecords and so on. Under the hood csw4js would put together a JSON object, use Jsonix (+ Mappings) to convert it to XML, handle client/server communication, transform the response XML to JSON (using Jsonix), process the response and return the resulting payload.

This is more or less what OL3 WPS GUI does. @bartvde could tell a bit more about it.

Sorry, have to round up for the moment, I'll write about the GetRecords use case tomorrow.

[bartvde]

@highsource @tomkralidis it's a hard choice to make if you deal with the raw JSON output or simplify it. Personally I have simply used the raw JSONIX parse output, it is verbose, but I think that is fine to start with. Also, simply using this structure will make writing the config back as string a lot easier.

[juanmav]

An example what @tomkralidis explains will be:

records.value.searchResults.abstractRecord[0].value.dcElement[3].value.content[0]

It get the title from a record from GetRecords. It can be a little tricky to a developer who don't know well the csw/ows responses (myself is an perfect example). But now I think would be a good solution to follow the @bartvde and @highsource recommendations and simplify the JSON response later.

[highsource]

@tomkralidis Here's my take on the GetRecords scenario. I'm not quite structured on it, but I hope this will give an idea.

First of all the developer creates a CSW client instance.

Csw4js.createClient(`http://...mygetcapabilitiesurl', function(client)
{
...
});

Under the hood Csw4js will make a HTTP GET request to the server (either on its own or via Jsonix, does not matter) and get the GetCapabilities response.

Then Csw4js will use Jsonix plus CSW mapping to unmarshall this response, getting JSON. Csw4js will know then the capabilities of the server and could configure the client accordingly: bindings for individual operations, supported record types and so on.

Since the request is async, the client will be also returned async - via callback or promises, something like that.

Having the client, the developer could now execute operations, for instance GetRecords:

client.getRecords(query, {startPosition: 1, maxRecords:5}, function(records){...});

Under the hood Csw4js build a JSON object based on the parameters, then uses Jsonix to marshall it to XML, makes a request to the server and get the response with records back. Then Csw4js uses Jsonix to unmarshall the XML into JSON, processes this JSON (i.e. fishes all of the records out of it) and gives the result back to the callback function provided by the developer.

Now the developer get an array of records in JSON form and does whatever he wants to with this JSON.

One of the missing fragments was the query. The easiest (from the development effort PoV) would be just to use Json according to the CSW/Filter mapping format, but it would be more convenient to write something like:

var constraint = new Filter4js.PropertyName('dct:type).eq('Service').and(
    new Filter4js.PropertyName('dct:modified).ge('2004-03-01'));

var query = new Csw4js.Query(['csw:Record'] // type names).elementSetName(...).constraint(constraint);

A kind of fluent API that ultimately builds JSON for Jsonix. As I said befor, Jsonix only does XML<->JSON, it takes away the pain of working with XML directly, but this is it. The CSW or Filter or GML API is out of the scope there, this must be done by the client. It's just (I hope, at least) easier to work on JSON level than on XML level.

A further thing is that these APIs (I mean CSW Query or Filter, for example) can be build gradually. Start with raw Jsonix according to the mapping and then build more into the API. More effort in the API -> less effort for the client developer but the whole thing works either way.

Jsonix wirks with modular mappings (each schema has its own mappings) which makes it quite easy to support scenarios with different record formats. For instance, just DC vs. also ISO 19139. When creating the CSW client the developer could pass a set of Jsonix mappings (something like [DC_1_1, DCT, ISO19139_20070417]). They don't have to be built or distributed with Csw4js, the developer could just load these mappings within the application. I think it would be even possible to load these mappings dynamically based on the GetCapabilities response, but that's somewhat black magic.

[highsource]

@tomkralidis @juanmav @bartvde

Next, there were a few questions on the verbosity of the Jsonix output. A few comments on that.

First of all, that's absolutely raw at the moment, I made zero effor to optimize the mappings in any way. :) There are quite a few things which can be done to make "better" mappings.

• The generation can be customized/simplified to produce better results (i.e. less x.value steps).
• Not supported yest but planned - so called adapters which would pre/postprocess JSON.
• You can easily exclude properties you don't need (however I don't think this is of much use here).

On the CSW level there's also these brief/summary/full element set types. Maybe this could be also leveraged in some way.

I don't quite have a feeling of whether verbose JSON is much of the problem or not. There are actually reasons for it to be verbose. Many things are required to adequately represent the schema (some are not, but most are). So cutting things may result in undesired effects. We could surely put adapters between raw Jsonix JSON and "beatified" output for the client application, the question is only, if the effort is worth the added value.

My suggestion would be to:

• optimize/simplify the generated mappings a bit with existing means
• use raw Jsonix JSON for starters to see how it goes
• have an option of adding adapter later on - as an option

I think this will (a) get things started without large effort and (b) allow for improvements without loss of backwards compatibility (old apps don't use adapters and have raw JSON, newer use adapters and have "beautified" JSON).

Sorry this is not as structured as I'd like it to be but I hope you see my points.

[juanmav]

@highsource Awesome! thanks for the feedback! In the coming days/week I think I can have a preview of this.

[juanmav]

@highsource

The commit with some of your ideas implemented. The code can by improve but at the moment i cant figure out how to build the constraint object with the filters. The constraint object returned by Jsonix differs a lot from the GetRecord & Query objects. Any suggestion?

Build GetRecords XML:

 // Create Constraint
var constraint = new Constraint();

// Create Query
var query = new Query('full', constraint);

// Create de GetRecords Action.
var recordAction = new GetRecords(1, 10, query);

// XML to Post.
var myxml = Csw4js.marshaller.marshalDocument(recordAction);

GetRecords

GetRecords = function(startPosition, maxRecords, query){
    this.name = {
        key: "{http://www.opengis.net/cat/csw/2.0.2}GetRecords",
        localPart: "GetRecords",
        namespaceURI: "http://www.opengis.net/cat/csw/2.0.2",
        prefix: "csw",
        string: "{http://www.opengis.net/cat/csw/2.0.2}csw:GetRecords"
    };
    this.value = {
        TYPE_NAME: "CSW_2_0_2.GetRecordsType",
        startPosition: startPosition,
        maxRecords: maxRecords,
        resultType: "results",
        service: "CSW",
        version: "2.0.2",
        abstractQuery: query
    };
};

Query

Query = function(elementSetName, constraint){
    this.name = {
        key: "{http://www.opengis.net/cat/csw/2.0.2}Query",
        localPart: "Query",
        namespaceURI: "http://www.opengis.net/cat/csw/2.0.2",
        prefix: "csw",
        string: "{http://www.opengis.net/cat/csw/2.0.2}csw:Query"
    }
    this.value = {
        TYPE_NAME: "CSW_2_0_2.QueryType",
        //constraint : {},
        elementSetName : {
            TYPE_NAME: "CSW_2_0_2.ElementSetNameType",
            value: elementSetName
        },
        typeNames : [
            {
                key: "{http://www.opengis.net/cat/csw/2.0.2}Record",
                localPart: "Record",
                namespaceURI: "http://www.opengis.net/cat/csw/2.0.2",
                prefix: "csw",
                string: "{http://www.opengis.net/cat/csw/2.0.2}csw:Record"
            }
        ]
    }
    if (constraint){
        this.value.constraint = constraint;
    }
};

Constraint

Constraint = function(){
    this.TYPE_NAME = "CSW_2_0_2.QueryConstraintType";
    this.version = "1.1.0";
    // How to build a filter?
    //this.filter ={}
};

Constraint.prototype.and = function(){

}

Constraint.prototype.or = function(){

}

[highsource]

@juanmav Filter comes from the filter encoding schema. I'll make an example here: highsource/ogc-schemas #44.

Generally, would be great to put such questions in issues so that we could track responses and capture answers for future reference.

I'll take a look at your code later on, but one thing now: don't reuse marshaller (I saw Csw4js.marshaller), reuse the context. Once created the context can be reused multiple times. Marshallers and unmarshallers are bound to one parsing/serializing operations. Can not be used in parallel and should not be reused.

[highsource]

@juanmav This is the XML you'd like to marshall, right? https://github.com/juanmav/csw4js/commit/fe03ee20e8b7d19a7c94a535b953e9797eabdd00 I'll take this for example.

[highsource]

Here's a current fiddle for unmarshalling:

http://jsfiddle.net/lexi/yq8x0oqf/

Looks indeed too verbose, but you don't need most of the TYPE_NAME properties. I'll make another one for marshalling. This can definitely be optimized.

[tomkralidis]

@highsource @juanmav thanks for the examples.

Can the JSON be more strongly typed, i.e.:

{
    "csw:GetRecords": {
        "maxRecords": 10,
        "resultType": "results",
        "service": "CSW", 
        "version": "2.0.2",
        "csw:Query": {
            "csw:ElementSetName": "full"
        }
    }
}

[highsource]

@tomkralidis

It's not about typing, it's about verbosity. Typing is already strong in a sense that you'll get types known in advance.

With two TODOs (see below) you can get the following structure:

{
  "name": "csw:GetRecords",
  "value": {
    "maxRecords": 10,
    "resultType": "results",
    "service": "CSW",
    "version": "2.0.2",
    "abstractQuery": {
      "name": "csw:Query",
      "value": {
        "typeNames": [ "csw:Record" ],
        "elementSetName": "full",
        "constraint": {
          // filter expression comes in here
        }
      }
    }
  }
}

Which is very close to what you want.

Jsonix does not use XML Element names as property names. So you have: { name: 'csw:GetRecords', value: {...} } instead of { 'csw:GetRecords' : {...} }. While the latter is a bit more concise, the first one is more "predictable" so to say.

The two todos are:

• Allow marshalling QNames from strings
• Allow simplifying value-only classes

Here's a more full commented JSON:

{
  // TODO 1: allow string-based "csw:GetRecords" instead (assumes the csw prefix is declared in context)
  // "name": { "namespaceURI": "http://www.opengis.net/cat/csw/2.0.2", "localPart": "GetRecords", "prefix": "csw" },
  "name": "csw:GetRecords",
  "value": {
    "maxRecords": 10,
    "resultType": "results",
    "service": "CSW",
    "version": "2.0.2",
    "abstractQuery": {
      // See TODO 1
      "name": "csw:Query",
      "value": {
        // See TODO 1
        "typeNames": [ "csw:Record" ],
        // TODO 2: Allow optimizing classes with just a single value property
        /*
        "elementSetName": {
          "TYPE_NAME": "CSW_2_0_2.ElementSetNameType",
          "value": "full"
        },
        */
        "elementSetName": "full",
        "constraint": {
          // filter expression comes in here
        }
      }
    }
  }
}

The first TODOs (marshalling of QNames) is trivial, can be done fast. The second is somewhat more complicated but is also not a big deal.

[tomkralidis]

@highsource thanks for the explanation. I think with the TODO itiems things brings us much closer.

Is there any reason why Jsonix does not use XML Element names as property names? Is the XML namespacing to JavaScript objects blocking this?

Having said this, it would be great to have some convenience functions that remove the necessity to check for the value of name attributes all the time for readers.

[highsource]

@tomkralidis See highsource/jsonix#52 for TODO 1 and highsource/jsonix#53 for TODO 2. I actually consider the latter to be a bug. I clearly did not wanted enums to be so verbose.

[highsource]

@tomkralidis

Is there any reason why Jsonix does not use XML Element names as property names? Is the XML namespacing to JavaScript objects blocking this?

This is a good point. To answer your question "why is this so":

• This is how it is done in JAXB (See JAXBElement).
• This makes the structure more strict. You always have name and value, not some property with the name not really known in advance.
• XML element names are (very often) qualified. So it's not 'csw:Record' but Record and http://www.opengis.net/cat/csw/2.0.2 as the namespace. The prefix csw is not significant and can be something different in a certain XML instance (tns or absent if you do xmlns="http://www.opengis.net/cat/csw/2.0.2"). At the same time you'd want a predictable structure in JSON, both for unmarshalling and after marshalling. An object with name and value is predictable, property names are fixed.

But you do have a good point:

{
    'csw:Record' : {...}
}

looks way better than

{
    name : 'csw:Record',
    value : {...}
}

Access is really A LOT easier with data['csw:Record'] than ... OK I don't even want to write the other one. By the way, if you're sure it's always csw:Record you can just write data.value. But if not - you'll have to iterate and check the name. Not good, I agree on that.

What bothers me is that 'csw:Record' depends on the namespace prefix (csw), which isn't fixed.

One way to address this would be to use '{http://www.opengis.net/cat/csw/2.0.2}Record' instead. This key is always the same, no matter what the prefix is. But it's ugly..

Another option is to use the prefix as configured in the Jsonix context. For instance, if you have:

// Create a Jsonix context var context = new Jsonix.Context(mappings, { namespacePrefixes: { 'http://www.opengis.net/cat/csw/2.0.2': 'csw' } });

Then it's clear that http://www.opengis.net/cat/csw/2.0.2 -> csw and therefore csw:Record is fixed in this context.

I have tried to apply all these changes to a sample JSON. Here's what I get.

Original:

{
    "name" : {
        "namespaceURI" : "http://www.opengis.net/cat/csw/2.0.2",
        "localPart" : "GetRecords",
        "prefix" : "csw"
    },
    "value" : {
        "maxRecords" : 10,
        "resultType" : "results",
        "service" : "CSW",
        "version" : "2.0.2",
        "abstractQuery" : {
            "name" : {
                "namespaceURI" : "http://www.opengis.net/cat/csw/2.0.2",
                "localPart" : "Query",
                "prefix" : "csw"
            },
            "value" : {
                "typeNames" : [ 'csw:Record', ],
                "elementSetName" : {
                    "value" : "full"
                },
                "constraint" : {
                    "version" : "1.1.0",
                    "filter" : {
                        "name" : {
                            "namespaceURI" : "http://www.opengis.net/ogc",
                            "localPart" : "Filter",
                            "prefix" : "ogc"
                        },
                        "value" : {
                            "logicOps" : {
                                "name" : {
                                    "namespaceURI" : "http://www.opengis.net/ogc",
                                    "localPart" : "And",
                                    "prefix" : "ogc"
                                },
                                "value" : {
                                    "comparisonOpsOrSpatialOpsOrLogicOps" : [ {
                                        "name" : {
                                            "namespaceURI" : "http://www.opengis.net/ogc",
                                            "localPart" : "BBOX",
                                            "prefix" : "ogc"
                                        },
                                        "value" : {
                                            "propertyName" : {
                                                "content" : "ows:BoundingBox"
                                            },
                                            "envelope" : {
                                                "name" : {
                                                    "namespaceURI" : "http://www.opengis.net/gml",
                                                    "localPart" : "Envelope",
                                                    "prefix" : "gml"
                                                },
                                                "value" : {
                                                    "srsName" : "urn:x-ogc:def:crs:EPSG:6.11:4326",
                                                    "lowerCorner" : {
                                                        "value" : [ -80, 150 ]
                                                    },
                                                    "upperCorner" : {
                                                        "value" : [ 80, -150 ]
                                                    }
                                                }
                                            }
                                        }
                                    }, {
                                        "name" : {
                                            "namespaceURI" : "http://www.opengis.net/ogc",
                                            "localPart" : "PropertyIsLike",
                                            "prefix" : "ogc"
                                        },
                                        "value" : {
                                            "escapeChar" : "\\",
                                            "singleChar" : "_",
                                            "wildCard" : "%",
                                            "propertyName" : {
                                                "content" : "dc:title"
                                            },
                                            "literal" : {
                                                "content" : [ "%WATER DEPTH%" ]
                                            }
                                        }
                                    } ]
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Optimized:

{
    "csw:GetRecords" : {
        "maxRecords" : 10,
        "resultType" : "results",
        "service" : "CSW",
        "version" : "2.0.2",
        "abstractQuery" : {
            "csw:Query" : {
                "typeNames" : [ "csw:Record", ],
                "elementSetName" : "full",
                "constraint" : {
                    "version" : "1.1.0",
                    "filter" : {
                        "ogc:Filter" : {
                            "logicOps" : {
                                "ogc:And" : {
                                    "ops" : [ {
                                        "ogc:BBOX" : {
                                            "propertyName" : "ows:BoundingBox",
                                            "envelope" : {
                                                "gml:Envelope" : {
                                                    "srsName" : "urn:x-ogc:def:crs:EPSG:6.11:4326",
                                                    "lowerCorner" : [ -80, 150 ],
                                                    "upperCorner" : [ 80, -150 ]
                                                }
                                            }
                                        }
                                    }, {
                                        "ogc:PropertyIsLike" : {
                                            "escapeChar" : "\\",
                                            "singleChar" : "_",
                                            "wildCard" : "%",
                                            "propertyName" : "dc:title",
                                            "literal" : [ "%WATER DEPTH%" ]
                                        }
                                    } ]
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

92 vs. 45 lines. The half. So I think the game is worth the candles. It's also not a big deal to implement it, but I'll have to think about backwards compatibility here.

So it looks like with a few (relatively small) fixes, the JSON part can be radically simplified. I've filed these issues and address them in the next days.

[highsource]

@juanmav

By the way, here's the latest working (but not yet optimized) JSFiddle:

http://jsfiddle.net/lexi/6skd7x8u/

I'll update it as I progress with the issues.

[juanmav]

@highsource I just realized the CSW_2_0_2_Full.js file does not include the filters declaration, is it ok? if not I can include it. I can make a pull request. Let me know.

[highsource]

Please file an issue to make Filters_..._Full. It should be optimized with GML. I'll add it then.

On Mon, Jan 26, 2015 at 4:20 PM, Juan Mahuel Vicente < notifications@github.com> wrote:

@highsource https://github.com/highsource I just realized the CSW_2_0_2_Full.js file does not include the filters declaration, is it ok? if not I can include it. I can make a pull request. Let me know.

— Reply to this email directly or view it on GitHub https://github.com/tomkralidis/csw4js/issues/1#issuecomment-71476404.

[juanmav]

https://github.com/highsource/ogc-schemas/issues/46

[juanmav]

I just made an update it has implemented few filter's features (in progress to improve).

But I realized the filter itself is not a CSW unique feature if not is a OGC Filter that can be used in another standard clients. So I guess well be good to make another project and the csw4js depends on it.

[highsource]

Yes, sure, Filter is used in many other OGC schemas, for instance WFS. I was also thinking a separate FilterJS.

[tomkralidis]

Perhaps we should move things to https://github.com/OSGeo/ows.js, which would include csw4js, given the cross-cutting support of dependency schemas, etc. Thoughts?

[highsource]

Way to go :+1:

I think it would be good to structure the whole thing as a few smaller modules which handle individual aspects. Like, there'll be filter4js module, csw4js, wps4js and so on.

[juanmav]

Great! Give me few days to have a proper implementation of filter4js (I will create a repo for it) and separate it from csw4js.

[highsource]

Ok, I'll concentrate on improving Jsonix then (see all these issues filed above). This will give you better/cleaner structures in JSON and standard scripts available via NPM and JSON so that you don't have to compile schema on your own. I'll also need a few days for that. :)

[tomkralidis]

@highsource @juanmav FYI there is an effort for a generic OWS JS client at https://github.com/OSGeo/ows.js (mailing list: http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs).

The more I think of it, it might be a good idea to move csw4js into ows.js as the starting implementation, of which CSW support is a part of (along with WMS/WFS/etc.). The fact that there are shared standards across / within the specs will allow us, for example, to write one Filter handler and use many times within the lib.

Thoughts?

[bartvde]

I agree @tomkralidis I think @highsource even proposed to meet up with some of the owsjs people at FOSSGIS in March, I'll be there as well

[juanmav]

@tomkralidis, ok so i will keep csw4js and filter4js together in the same project.

[tomkralidis]

@juanmav I'm thinking to move csw4js to ows.js and we continue the work there?

[juanmav]

@tomkralidis ok, let's go there!

[juanmav]

@tomkralidis @highsource I'm making some progress with the CSW, I think the next step is to rewrite the "GetCapabilities", to deprecate the xml navigation. At the moment the filter4js only has implemented the and, bbox and isLike operators.

[tomkralidis]

Awesome! FYI I'll setup https://github.com/OSGeo/ows.js and let everyone know when things are ready to continue from there.

Sent from my iPhone

On Jan 30, 2015, at 16:21, Juan Mahuel Vicente notifications@github.com wrote:

@tomkralidis @highsource I'm making some progress with the CSW, I think the next step is to rewrite the "GetCapabilities", to deprecate the xml navigation. At the moment the filter4js only has implemented the and, bbox and isLike operators.

— Reply to this email directly or view it on GitHub.

[highsource]

@juanmav @tomkralidis Good work guys.

I'm working on highsource/jsonix#56. Almost got it.

[tomkralidis]

@highsource @juanmav @bartvde FYI I've now moved csw4js into https://github.com/OSGeo/ows.js and am sending an update to the ows.js mailing list (http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs) See you over there!