On Wed, Feb 9, 2011 at 8:47 AM, Ben Caradoc-Davies
wrote:
> [Back on the list]
>
> Unit test. It is the only way to be sure.
Yup. For the moment I was just checking the waters before wasting needless time
in a quote for something others might know it's just not doable
Cheers
Andrea
--
[Back on the list]
Unit test. It is the only way to be sure.
Kind regards,
Ben.
On 09/02/11 15:42, Andrea Aime wrote:
> On Wed, Feb 9, 2011 at 4:14 AM, Ben Caradoc-Davies
> wrote:
>> I was thinking about non-feature polymorphic complex properties. For
>> example, CGI_Value and similar types f
There is an open source package called trang that converts an xml
document to an xml schema, among other things
http://www.thaiopensource.com/relaxng/trang-manual.html#xml-input
It is used by oXygen.
Tara
Gabriel Roldán wrote:
Still I think it could be possible to grab a hand made Featu
I was thinking about non-feature polymorphic complex properties. For
example, CGI_Value and similar types from GeoSciML 2.0:
http://www.geosciml.org/geosciml/2.0/xsd/value.xsd
The GML striping rule requires that the type (XSD element) is encoded
before each property name. BindingPropertyExtracto
Cannot read features from SQL datastore with NaN numeric values
---
Key: GEOT-3421
URL: http://jira.codehaus.org/browse/GEOT-3421
Project: GeoTools
Issue Type: Bug
Compone
Still I think it could be possible to grab a hand made FeatureType and
derive its xsd, right? Even if it may break right now, it shouldn't be
that complicated?
What do you mean the encoder needs to know about substitution groups?
can't it work if there are no substitution groups? The FeatureType
it
Andrea,
there is no support for converting complex FeatureTypes into schemas.
app-schema delivers schemas by returning a document that includes or
imports the application schemas from their canonical location.
The GML encoding requires a schema document to feed into EMF to
configure the encode
Improve PropertyCollector in ImageMosaic
-
Key: GEOT-3420
URL: http://jira.codehaus.org/browse/GEOT-3420
Project: GeoTools
Issue Type: Improvement
Components: gc imagemosaic
Affects Vers
On Tue, Feb 8, 2011 at 10:54 AM, Andrea Aime
wrote:
> On Tue, Feb 8, 2011 at 6:39 PM, Justin Deoliveira
> wrote:
> > While I very much appreciate the work the appschema folks have been doing
> I
> > do agree that there is room for a solution that does not involve xml
> schema
> > mapping, as your
On Tue, Feb 8, 2011 at 6:39 PM, Justin Deoliveira wrote:
> While I very much appreciate the work the appschema folks have been doing I
> do agree that there is room for a solution that does not involve xml schema
> mapping, as your use case and past experiences clearly indicates.
> As for going fr
While I very much appreciate the work the appschema folks have been doing I
do agree that there is room for a solution that does not involve xml schema
mapping, as your use case and past experiences clearly indicates.
As for going from featureType to xml schema without a predefined schema (for
com
Hi,
I'm asking to satisfy a curiosity. I know that complex feature people
are all about
interoperability with application schemas and the like, but only the
cases demanding
complex features I keep on stumbling on do not use/require published
app schemas at all...
I'm wondering, assuming I can make
we do. If you find any problem just report back as a bug. But it's
already supported (though only tested against Oracle11g).
Cheers,
Gabriel
On Tue, 2011-02-08 at 11:29 +0800, Ben Caradoc-Davies wrote:
> Gabriel,
>
> do we support or plan to support ArcSDE 10 as a datastore backend?
>
> Kind rega
13 matches
Mail list logo
