Survey among OSLC TRS implementers


Andrii Berezovskyi
 

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 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

 

Best regards,

Andrew

 

OSLC OP PGB co-chair


David Honey2
 

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.

 

Best regards,

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Andrii Berezovskyi
Sent: 07 April 2022 16:06
To: oslc-op@...
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

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 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

 

Best regards,

Andrew

 

OSLC OP PGB co-chair


Jim Amsden
 

Agree, can you add your comment to the issue?

 

From: <oslc-op@...> on behalf of David Honey2 <david.honey@...>
Reply-To: "oslc-op@..." <oslc-op@...>, David Honey2 <david.honey@...>
Date: Thursday, April 7, 2022 at 11:26 AM
To: "oslc-op@..." <oslc-op@...>, "andriib@..." <andriib@...>
Subject: [EXTERNAL] Re: [oslc-op] 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 ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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.

 

Best regards,

David.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Andrii Berezovskyi
Sent: 07 April 2022 16:06
To: oslc-op@...
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

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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 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

 

Best regards,

Andrew

 

OSLC OP PGB co-chair