OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org] On Behalf Of David Honey1
Sent: Thursday, April 19, 2018 6:16 AM
To: Ian M Green11 <ian.m.green@uk.ibm.com>
Cc: oslc-core@lists.oasis-open.org
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 <ian.m.green@uk.ibm.com>
To:        oslc-core@lists.oasis-open.org
Date:        19/04/2018 09:45
Subject:        [oslc-core] Dealing with unsupported literal value types
Sent by:        <oslc-core@lists.oasis-open.org>





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
ian.m.green@uk.ibm.com

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]