The community schema output is defined in terms of GML3.1.1, we need to formalize our GML3.1.1 technology and code this up.
There are two choices:
1. Making use of the GTXML (aka schema assied parsing) bindings, and using them for printing
2. Using the existing XML Tranformer technology in geotools, that I think Gabriel has extended already?
Justin - I know you have requested a review of your xml generation APIs, I still have more normal requirement (XML schema is a program, we should not have to code anything in Java that has already been writenin XML schema). Now we cannot get 100%, for WFS both GML3 and WFS define something that can capture a FeatureCollection - let the user choose, or choose the longest" chain. You can also review the existing XDO printing bindings for inspiration.
For those following at home:
Justin if you do not have enough time to figure this one, please check if Gabriel would be willing to maintain his existing GML3 generation code a bit longer.
I have given this the default 2 week estimate, please adjust to reflect your experience.
CodeHaus Comment From: jgarnett - Time: Fri, 3 Mar 2006 01:27:48 -0600
<p>Sweet - let me see if I understand this.</p>
<ul class="alternate" type="square">
<li>data queries against attribute names - check that is how it is supposed to be</li>
<li>not sure what you mean by "update path" not being traced?</li>
<p>You may notice that AttributeName has a put/get client properties allowing opperation (GML writing in this case) to recrod things like the XML namespace prefix? Does this help? Or am I complicating things by trying to make your life easier?</p>
<p>This Jira task is for GML3.1.1 generation, I am not sure how FeatureType.create fits into anything? The constructor you mention does not seem like a bad idea, and constructors do not effect the intreface API so all should be fine.</p>
<p>I should hope that this extra information can aliviate the need to configure the FeatureTransformer before use...</p>
CodeHaus Comment From: groldan - Time: Fri, 3 Mar 2006 05:54:22 -0600
<p>>This Jira task is for GML3.1.1 generation, I am not sure how FeatureType.create fits into anything?
hmm. yeah, I guess I just mixed stuff on the logging statement.</p>
<p>put/getClientProperty is actually a very good idea. I would use it not just for tracking ns prefixes, but also for mapping custom element attributes from intput schema properties to outpus schema gml attributes (i.e. <gml:name codeSpace="..." )
What we should agree is what kind of information goes as client property keys. I guess we can just follow "standard" factory hints usage and put a Class as key? like
AttributesImpl atts = new AttributesImpl();
<p>another option would be defining a well known set of string keys? </p>
CodeHaus Comment From: groldan - Time: Fri, 3 Mar 2006 05:56:53 -0600
<p>resolving since it is working on cpx.
Will no close as a reminder since I guess we'll have to move it to next phase to resolve the custom schema attributes issue mentioned previously.</p>
CodeHaus Comment From: jgarnett - Time: Fri, 3 Mar 2006 05:59:34 -0600
<p>It is kind of up to you Gabriel, the facility is for application specific data - in this case GeoServer. Hints for schema mapping is right on target. And use of class <b>can</b> be more efficient then String, but make sure you are not loading a class <b>just</b> to use it as a Key, I have been caught out on some classloader performance issues this way before.</p>
CodeHaus Comment From: aaime - Time: Thu, 29 Mar 2007 02:06:37 -0500
<p>These issue has been in resolved state for at least one month (quite a bit, a lot more than one month). Batch transitioning them to closed state</p>