You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
xsd:int allows 4GB string size, xsd:long allows 9EB string size (that's 9 exabytes, or 9000 petabytes). xsd:integer allows values longer than that. I think the OSLC OP should consider downgrading the datatype from xsd:integer to xsd:long.
Otherwise, it creates implementation problems. See eclipse-lyo/lyo#272 (comment) for an example of such a discussion (I am not even mentioning the unnecessary impact on performance). Further, some programming languages don't even come with arbitrary-precision arithmetic support out of the box (C and C++ are the two most prominent examples), which negatively limits OSLC applicability.
The text was updated successfully, but these errors were encountered:
Neither xsd:int nor xsd:long are supported OSLC data types. If we wanted to use them, we would need to update OSLC Core to add them as supported data types, and OSLC Query to describe their semantics in queries.
https://docs.oasis-open-projects.org/oslc-op/core/v3.0/os/core-shapes.html#PropertyShape indicates that
oslc:maxSize
is used to limit string length.xsd:int
allows 4GB string size,xsd:long
allows 9EB string size (that's 9 exabytes, or 9000 petabytes).xsd:integer
allows values longer than that. I think the OSLC OP should consider downgrading the datatype fromxsd:integer
toxsd:long
.Otherwise, it creates implementation problems. See eclipse-lyo/lyo#272 (comment) for an example of such a discussion (I am not even mentioning the unnecessary impact on performance). Further, some programming languages don't even come with arbitrary-precision arithmetic support out of the box (C and C++ are the two most prominent examples), which negatively limits OSLC applicability.
The text was updated successfully, but these errors were encountered: