RO should define platform-independent primitive types

[abstratt]

Property types should not expose the platform specific types used in the implementation. Instead, RO implementations should expose only platform independent types.

Example, from Isis RO viewer:

http://mmyco.co.uk:8180/isis-onlinedemo/restful/domain-types/TODO/properties/description

{
"rel" : "urn:org.restfulobjects:rels/return-type",
"href" : "http://mmyco.co.uk:8180/isis-onlinedemo/restful/domain-types/java.lang.String",
"method" : "GET",
"type" : "application/json;profile="urn:org.restfulobjects:repr-types/domain-type""
}

[danhaywood]

Thanks, Rafael... I agree. Will look to update in a future version of the spec.

[darabi]

I just started the simpleapp demo and was very surprised to find java.lang.String. How does the viewer deal with this? Does it support one string type for dot-net and one for Java?

[abstratt]

@darabi You can still look at a RO type called 'java.lang.String' and interpret it in a way that makes sense in your implementation platform. IMO, this ticket is more an issue of aesthetics than anything.

[darabi]

From one perspective, yes. But it becomes problematic when I want to implement the spec in another language than Java.

And even if I just wanted to consume the API: as the number of implementations grows, would I have to write conditionals for half a dozen of different primitive types for different languages for being able to consume a string literal correctly?

[danhaywood]

Nice to see this conversation going on.

When I wrote the spec I did do quite a lot of thinking about datatypes, and there's a discussion about them in section 2.5 of the spec (v1.0). So actually, it's probably correct to say that this is an error in the implementation, but the spec has you covered. So if you want to go ahead and write a different implementation, you can.

If you weren't aware, there is actually another implementation of the RO spec, namely by the Naked Objects framework. So it's certainly "do-able".

[abstratt]

@darabi Right, with multiple server implementations, you need to be able to handle both correct 'string' and the incorrect 'java.lang.String' type ids, which is indeed a pain.