app-schema is stuck on GEOT-2505 for xlink and any other gml data type attribute support. Hopefully we can get a chance to deal with this at FOSS4G :-)
I am not aware of any proposed changes, especially any proposals "not accepted" by the app-schema team - is there some changes proposed on a back-channel, and not accepted by others that we havent been told about? As far as I know we are waiting for some stuff to be checked in by Justin so we could look at it, but this is about 2 months ago. as a PSC member, I'd be happy to vote to ignore xlinks while its just a hack - passing the CITE tests for a special case is kind of bypassing the point of the CITE tests IMHO. These are conformance tests for a capability - if the capability is a hack, this is not a great situation. Rob On Mon, Oct 12, 2009 at 1:58 AM, Justin Deoliveira <[email protected]> wrote: > You have to explicitly specify to run the xlink tests, so very easy, > just don't click the check box :) > > Jody Garnett wrote: >> Okay quick sanity check question; can we "turn off" support for xlink >> and have the cite test skip that part? I am only focused on if we can >> make a release candidate today or not; and if we can make use of >> volunteers for to help test. >> >> I am with Justin; ditch xlink support; get 2.0 out the door since we met >> our goal of having a new user interface; and make plans for xlink later >> when people have time to think. >> >> A PSC vote won't actually hep or hinder right now; only hands helping >> out. And we have lined up hands to help test :-) >> >> Jody >> >> >> On 11/10/2009, at 6:47 AM, Andrea Aime wrote: >> >>> Justin Deoliveira ha scritto: >>>> Ok, looked into the test failures. And bottom line is that the hacks >>>> put in place for xlink are tripping over work done by the app-schema >>>> folks. Before app-schema was in place i was free to make wild >>>> assumptions and hack to high heaven to get things working. But now >>>> that certain types and bindings are being used those hacks fall apart. >>>> Unfortunately I don't see an easy way forward on this. I could spend >>>> time trying to rework my hacks but quite frankly I a) don't have the >>>> time right now and b) don't see the point. The xlink "implementation" >>>> (if you can call it that) was just an experiment (and in my opinion a >>>> premature one) in an OGC test bed. Nobody else as far as i know >>>> implements xlink, and i can't think of one client who could possibly >>>> be using it. >>>> However it has been my intention to get rid of the nasty hacks and >>>> replace them with a working app-schema configuration now that we have >>>> one. But this is not a trivial piece of work. I spent half a day >>>> trying to do so and met limited success, and it required patches to >>>> app-schema which were not accepted at the time. >>> >>> Interesting. Is the app schema team going to work over xlink support >>> anytime soon? Anyone? >>> >>>> So I leave it up to the PSC to decide but if it were my call I would >>>> say ditch xlink for now until we can get a working app-schema >>>> replacement for what is there on 1.7.x. And keep the OGC happy with >>>> 1.7.x as their "xlink reference implementation" until that happens. >>> >>> I agree with the reasoning. On one side I think we should call a PSC >>> vote, on the other side, a PSC vote won't materialize resources by >>> magic: if there is no one with the ability to work on this, it won't >>> be done, it's as simple as that. (no?) >>> >>> Soo... opinions? Maybe we should start a separate thread to discuss this. >>> >>> Cheers >>> Andrea >>> >>> >>> PS: does that mean we get remove the code that >>> in JdbcDataStore handles geometric association? :-p >>> Sorry, could not resist!! >>> >>> -- >>> Andrea Aime >>> OpenGeo - http://opengeo.org >>> Expert service straight from the developers. >> > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
