Mauro,

your proposal seems like a good idea, and would improve usability where 
the encoder should not require explicit direction. I was simply offering 
a workaround while I thought about it.  :-)

My main concern is the interaction with type conversion. What if an 
app-schema mapping uses targetAttributeNode to set an anyType to a 
MeasureType or CodeType (or some other complex type that extends a 
simple type)? Would this type coercion still be honoured if the encoder 
is permitted to use the concrete type of the source value?

I am happy to review any pull request; I would run the full suite of 
GeoServer app-schema online tests against postgis. This is the most 
comprehensive set of app-schema mapping tests we have. Even offline 
tests also have anyType coverage.

Kind regards,
Ben.

On 26/02/15 21:19, Mauro Bartolomeoli wrote:
> Hi Ben,
> probably you are right, declaring that targetAttributeNode is used in a
> wrong way in my usecase, I added it trying to understand why the lcv:class
> attribute (declared as xs:anyType) was not encoded in GML. Probably, after
> the patch to anyType handling I talk about in my email (that's the main
> point of my issue, not the targetAttributeNode usage) it would work also
> without it (I will try).
>
> The main issue remains: is it correct to add handling of "primitive"
> (simple)  types to xs:anyType bindings and which approach seems better to
> you, changing ComplexSupportXSAnyTypeBinding or its parent class
> XSAnyTypeBinding?
>
> Any hint is appreciated.
>
> Thanks
> Mauro Bartolomeoli
>
> 2015-02-25 21:32 GMT+01:00 Ben Caradoc-Davies <b...@transient.nz>:
>
>> Mauro,
>>
>> targetAttributeNode must be applied to the containing property type
>> lcv:landCoverObservation[1]/lcv:LandCoverObservation, not the terminal
>> node. I am not sure exactly what you should use in this case, but please
>> see these pages for examples:
>> http://docs.geoserver.org/latest/en/user/data/app-
>> schema/mapping-file.html#targetattributenode-optional
>> http://docs.geoserver.org/latest/en/user/data/app-
>> schema/polymorphism.html#any-type
>>
>> Kind regards,
>> Ben.
>>
>> On 25/02/15 23:24, mauro.bartolomeoli wrote:
>>
>>> Hi,I have an unexpected behaviour in app-schema mappings, when I have to
>>> deal with an attribute declared as xs:anyType.
>>>
>>>   From my understanding of the xs:anyType meaning, this can be mapped to
>>> simple (xs:string, etc.) or complex types.
>>> Currently if I map an xs:anyType attribute to an xs:string it doesn't get
>>> encoded in the final GML3 document.
>>>
>>>
>>> This is the mapping configuration:
>>>
>>>
>>>       <AttributeMapping>
>>>           <targetAttribute>
>>>               lcv:landCoverObservation[1]/lcv:LandCoverObservation/lcv:
>>> class
>>>           </targetAttribute>
>>>           <targetAttributeNode>xs:string</targetAttributeNode>
>>>           <sourceExpression>
>>>               <OCQL>UCS2007</OCQL>
>>>           </sourceExpression>
>>>       </AttributeMapping>
>>>
>>>
>>> lcv:class is declared in its xsd as xs:anyType.
>>>
>>>
>>>
>>> As you can see I am explicity declaring xs:string as the target attribute
>>> node type, and the app-schema mapping seems to work well with it. The
>>> problem seems to be the encoder, that uses ComplexSupportXSAnyTypeBinding
>>> to encode xs:anyType attributes.
>>>
>>>
>>> This binding class currently only support ComplexAttribute objects, but
>>> with my mapping the value is a simple String, so it doesn't get encoded at
>>> all.
>>>
>>>
>>> My idea is to change the encode method to:
>>>    1) call super.encode(...) when the value is not a ComplexAttribute
>>>    2) implement the encode method in the parent class (XSAnyTypeBinding)
>>> to handle simple value encoding, something like:
>>>
>>>
>>>       public Element encode(Object value, Document document, Element
>>> element)
>>>                          throws Exception {
>>>          if (value != null) {
>>>               Text text = document.createTextNode(Converters.convert(value,
>>> String.class));
>>>               element.appendChild(text);
>>>           }
>>>          return element;
>>>      }
>>>
>>>
>>> In alternative I can do all the work in ComplexSupportXSAnyTypeBinding
>>> encode method, without touching XSAnyTypeBinding.
>>>
>>>
>>> Anyone with app-schema / complex types experience can give me an advice
>>> on this?
>>>
>>>
>>> Thanks
>>> Mauro
>>>
>>>
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>>
>>>
>>> Dott. Mauro Bartolomeoli
>>> @mauro_bart
>>> Senior Software Engineer
>>>
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax:     +39 0584 1660272
>>>
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>>
>>> -------------------------------------------------------
>>>
>>>
>>> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003Le informazioni contenute in
>>> questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da
>>> considerarsi strettamente riservate. Il loro utilizzo è consentito
>>> esclusivamente al destinatario del messaggio, per le finalità indicate nel
>>> messaggio stesso. Qualora riceviate questo messaggio senza esserne il
>>> destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di
>>> procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro
>>> sistema. Conservare il messaggio stesso, divulgarlo anche in parte,
>>> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
>>> diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs.
>>> 196/2003. The information in this message and/or attachments, is intended
>>> solely for the attention and use of the named addressee(s) and may be
>>> confidential or proprietary in nature or covered by the provisions of
>>> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's
>>>
>> New Data Protection Code).Any use not in accord with its purpose, any
>> disclosure, reproduction, copying, distribution, or either dissemination,
>> either whole or partial, is strictly forbidden except previous formal
>> approval of the named addressee(s). If you are not the intended recipient,
>> please contact immediately the sender by telephone, fax or e-mail and
>> delete the information in this message that has been received in error. The
>> sender does not give any warranty or accept liability as the content,
>> accuracy or completeness of sent messages and accepts no responsibility
>> for changes made after they were sent or for other risks which arise as a
>> result of e-mail transmission, viruses, etc.
>>
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>> --
>> Ben Caradoc-Davies <b...@transient.nz>
>> Software Engineer
>> Transient Software <http://transient.nz>
>> New Zealand
>>
>
>
>

-- 
Ben Caradoc-Davies <b...@transient.nz>
Software Engineer
Transient Software <http://transient.nz>
New Zealand

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to