Right. I would like to hear Ben's take but in general I don't think many of
the other models actually use the xlink model for anything other than the
purpose of generating their own initial model. So i would say if everything
compiles just change it in place as is. One thing that would be good is to
see how this affects "regenerating" one of the other models that depends on
it.
As for title model maybe sticking with object is safer just in case? No
strong opinion there though.
On Mon, Nov 19, 2012 at 12:03 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Mon, Nov 19, 2012 at 4:38 PM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> On Mon, Nov 19, 2012 at 4:23 PM, Justin Deoliveira
>> <jdeol...@opengeo.org>wrote:
>>
>>> I leave it to you, but i would be fine with just updating the existing
>>> module, especially since eventually i think it makes more sense to merge it
>>> and follow suite with wcs 1.0 and 1.1. To do this you will have to tweak
>>> some stuff on model generation, basically renaming the ecore package to
>>> wcs20, which you will probably do anyways because the wcs schema uses
>>> version numbers that emf maps to strange package names.
>>
>>
>> Yep, the first model out of XSD is normally too ugly anyways, have to
>> change package names,
>> fix property classes and the like to get it in some usable shape
>>
>
> So trying to create this new module I made some "nice" discovery.
> WCS 2.0 depends on OWS 2.0, which needs to be generated too... and so far,
> no particular problem.
> Now, OWS 2.0 depends on (wait for it) the new xlink stuff... bhwaaaggh!
>
> Looking at it, it seems to me the model is a proper superset old xlink
> stuff, in that
> the two model classes we already have are represented the same way, but
> there are several other new attributes we need to care for.
>
> The namespace is also the same, so it seems to me the clean approach would
> be to just
> overwrite what we have with the new beans, which should result in a mere
> addition of
> new EMF objects.
>
> I've tried this, and it seems to work... as usual EMF gets confused by
> xs:any usage
> which is present in some element, for example:
>
> <xs:group name="titleModel">
> <xs:sequence>
> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
>
> Err... ideas of how to best deal with this? Shall I just refactor the
> model to
> force the usage of a String? Or of an Object?
>
> I've also attached what I got so far.
>
> Cheers
> Andrea
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
