[OASIS Issue Tracker] (OSLCCORE-170) Core 3.0 Literal Value Types are closed

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69945#comment-69945 ] 

Andrii Berezovskyi commented on OSLCCORE-170:
---------------------------------------------

I am in favour of supporting as many literal types as possible because it's the easiest way to add some validation (ie property x < 2^31) and semantics (ie the resource with property y has a certain duration) without shapes or inferencing.

> Core 3.0 Literal Value Types are closed
> ---------------------------------------
>
>                 Key: OSLCCORE-170
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-170
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: New Feature
>          Components: Core
>            Reporter: ian green
>            Assignee: James Amsden
>            Priority: Minor
>
> 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? 
> [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" 
> Suggestion: Core 3.0 data types should be open, or at least more generous that the current small set.
> Core 2.0 suffers the same issue; guidance on how a core 2.0 implementation should deal with unsupported types would be useful.



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)