RE: [oslc-core] Dealing with unsupported literal value types

Yes, I knew that part of OSLC Core 2.0.

Any idea why those restricted choices were made?

Why not support all xsd types, for example?

From:      
 "Sarabura, Martin"
<>

To:      
 David Honey1 <>,
Ian M Green11 <>

Cc:      
 ""
<>

Date:      
 19/04/2018 13:10

Subject:    
   RE: [oslc-core]
Dealing with unsupported literal value types

It goes back to open-services.net: http://open-services.net/bin/view/Main/OslcCoreSpecification#Defining_OSLC_Properties

 

 

From: 
[mailto:]
On Behalf Of David Honey1

Sent: Thursday, April 19, 2018 6:16 AM

To: Ian M Green11 <>

Cc: 

Subject: Re: [oslc-core] Dealing with unsupported literal value types

 

I've wondered the same thing. For example,
integers have to be xsd:integer and not xsd:int. Yet servers based on traditional
RDBMs will probably use 32 bit integers and xsd:int is a better fit for
the data. If the intent was to keep to well-defined standard data types,
why not support more, most, or perhaps all xsd data types?

Perhaps others who served on OSLC longer can shed light on the background
of that decision. 

David. 

From:        Ian M
Green11 <>

To:        

Date:        19/04/2018
09:45 

Subject:        [oslc-core]
Dealing with unsupported literal value types

Sent by:        <>

Core 3.0 specifies a closed set of data types for literals [1].

Is there any advice/suggestion on how an implementation should deal with
resources and their shapes when other data types are involved?  

For example, I work on an application that uses xsd:duration internally,
and currently the OSLC representations of that type is identical and hence
non-compliant.  We could (i) live with this non-compliance, (ii) refrain
from exposing resources of such types on the OSLC API, or (iii) pick some
other data type that is supported and map values into that supported type.
 For (iii) xsd:string comes to mind.

What is the preferred approach?

As an aside, I don't recall the design rationale that led to a closed set
of data types, which leads me to question that decision.  Should Core
be less prescriptive and leave the set of types open?

[1] http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part6-resource-shape/oslc-core-v3.0-cs01-part6-resource-shape.html#property-shape,
"Literal Value Types"

regards 

       -ian 

Ian Green



Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU 

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU