Re: Survey among OSLC TRS implementers
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:
An XML fragment.
A decimal number.
A double precision floating point number.
A single precision floating point number.
A string with a language tag. Unless otherwise specified, anywhere OSLC uses xsd:string, rdf:langString may also be used.
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.
From: oslc-op@... <oslc-op@...> On Behalf Of Andrii Berezovskyi
Sent: 07 April 2022 16:06
Subject: [EXTERNAL] [oslc-op] Survey among OSLC TRS implementers
Hello, We would like to ask you about how you implemented the `trs:order` data property in your programming language. According to the spec, it is of `xsd:integer` type, which is unbound and, for example, needs a BigInteger in Java to faithfully ZjQcmQRYFpfptBannerStart
We would like to ask you about how you implemented the `trs:order` data property in your programming language. According to the spec, it is of `xsd:integer` type, which is unbound and, for example, needs a BigInteger in Java to faithfully map one to the other. Eclipse Lyo, for example, is using a Java Integer, which is only 32 bits wide.
We are considering in OSLC-572 and LYO-135 to make a change both ways: to narrow the `trs:order` type in the OSLC TRS shapes from `xsd:integer` down to `xsd:long` and to broaden the type of a backing field in Eclipse Lyo from a Java Integer to a Long.
Please respond if you are using TRS in your deployments to help us understand the impact of this potentially breaking change to the spec. You can respond here or, preferably, under https://github.com/oslc-op/oslc-specs/issues/572
OSLC OP PGB co-chair