[geotk] CSW client : unmarshalling issue

[Guilhem]

Hello Damiano,

I look more closely to the issue of QName in PropertyName, I started to 
change the type of the attribute and then i realize why we don't do it 
before.
the problem is that we have to handle XPath in that kind of Field.
That why i can't use directly a QName object.

Guilhem Legal

Le 12/05/2011 18:17, Damiano ALBANI a écrit :
> On 05/12/2011 06:03 PM, Guilhem wrote:
>> <ogc:PropertyName>http://www.opengis.net/cat/csw/apiso/1.0:Identifier</ogc:PropertyName> 
>>
>>
>> I don't know, if this will satisfy degree. I'll try to see if i can 
>> handle this better when i'll have some time.
>
> I can't say if it's legal CSW but deegree doesn't like it very much. 
> It throws no error but doesn't take the identifier value into account 
> and deletes everything in the store ! I shall ask over at deegree if 
> that's a bug or not.
>
> By the way, regarding those PropertyTypes, I've seen something strange 
> about the signatures in the API.
> For example:
>
> PropertyIsEqualToType(LiteralType literal, PropertyNameType 
> propertyName, Boolean matchCase);
> PropertyIsEqualToType.setPropertyName(String propertyName);
>   vs.
> PropertyIsLikeType(Expression expr, String pattern, String wildcard, 
> String singleChar, String escape);
> PropertyIsLikeType.setPropertyName(PropertyNameType propertyName);
>
> See the difference between raw String vs. complex objects. Is there 
> any particular reason for that?
the setter PropertyIsEqualToType.setPropertyName(String propertyName); 
was actually doing new PropertyNameType(propertyName)

i add a second setter with propertyNameType
>
> The workaround I found is to use *either* the constructor or the 
> setters, depending on whether I need to input a Java object or a CQL 
> query as a String.
>
> Regards,
>