On 14/10/15 02:31, Stefano Costa wrote: > I tried to mimic what you did to support complex types with simple content, > here is the PR: > https://github.com/geotools/geotools/pull/994 > The reasoning behind it is that if a complex type is derived from > xs:anyType by extension (not restriction) and has mixed content, one could > legitimately want to set the contents of an element with such a type to > whatever one likes: so, if somebody tries to set its value to a > non-Collection type, I convert it to a String and store the result in a > special "unrestrictedContent" property, which is then encoded as text.
My understanding is that mixed content is expressly prohibited by the GML encoding rules. See section 7 of OGC 07-036 (the GML 3.2.1 standard), and the similar section in the GML 3.1.1 standard. A GML property can be either simple or complex, but not mixed. See 7.1.1, the discussion in note 3 on p21, and 7.2.3.1 on p24. GML is designed to be a self-describing serialisation of an abstract information model, and mixed content would break this design. If mixed content is prohibited, would this change your implementation? I am not sure that unrestrictedContent is a self-explanatory name, but I am trying to enlarge my understanding. > With this patch, I could successfully encode a swe:DataArray/swe:values > element with string content. Good. Your code and test coverage are thorough as usual. My main concern is that it is too general and may work for cases that should not be supported as they are prohibited by the GML encoding rules. > I'm not 100% sure this makes sense though and I'd very much appreciate your > review :-) I am still trying to understand it. Kind regards, -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
