Consider using xsd:long in TRS instead of xsd:integer

[berezovskyi]

xsd:integer is unbound and needs BigInteger in Java to map fully. My guess is that many apps use Long fields to back xsd:integer properties (the major benefit being the ability to use AtomicLong, esp for TRS log modification tasks with very little cost).

See also eclipse/lyo#135 (comment)

[DavidJohnHoney]

Most IBM Rational ELM TRS implementations have specific code to construct the RDF representation of TRS events rather than relying on Jena’s automatic conversion of Java types to literals. The underlying persistence in the RDB is likely to be long, but it will always be represented in RDF has a typed literal of type xsd:integer as per the specification.

OSLC Core (see Literal Value Types in https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/resource-shape.html#property-shape) currently only supports the following literal types:

rdf:XMLLiteral
     An XML fragment.
xsd:boolean
     A boolean.
xsd:dateTime
     A date-time.
xsd:decimal
     A decimal number.
xsd:double
     A double precision floating point number.
xsd:float
     A single precision floating point number.
xsd:integer
     An integer.
xsd:string
     A string.
rdf:langString
     A string with a language tag. Unless otherwise specified, anywhere OSLC uses xsd:string, rdf:langString may also be used.

There are other cases where OSLC specifications specify xsd:integer.

I vote against making such a change to the TRS specification. It would be a breaking change since xsd:int or xsd:long is a narrowing of the current xsd:integer datatype. It would potentially make all the existing TRS implementations non-conformant, and make the TRS specification inconsistent with other specifications where xsd:integer is used. It would also require a change to OSLC Core to allow such additional literal types, and I don’t think this is a strong enough case for doing so.

[berezovskyi]

We have decided to switch to BigInteger in Lyo even if this proposal goes through. I am still suggesting to go forward with the proposal until someone shows me a TRS Server returning anything larger than Long.MAX_VALUE and a TRS Client that can handle Long.MAX_VALUE+1. I will definitely test if a J*zz TRS Client can handle my TRS Server log with order ids starting from Long.MAX_VALUE-1 and going up 🧑‍🔬 🧨😏