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: [OASIS Issue Tracker] (OSLCCORE-58) Expand oslc:valueType allowed values

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

James Amsden commented on OSLCCORE-58:

Yes, Martin, the shapes specification implies that if a dcterm:created property value is of type xsd:dateTime, then a client should interpret the value as a dateTime. However if the value is of type xsd:date, or any other type, the resource does not satisfy its applicable shapes, and a client would be expected to "do something reasonable" which would be to parse the date properly and extract the date and set the time to 0.

However, one of the purposes of any standard, and in particular the primitive type shapes constraints is to foster interoperability and integration. So clients and servers might benefit from satisfying the shapes unless there's some compelling reason they can't. Parsing date formats has been a particular source of interoperability issues over the years.

In the case of dateTime vs. date, dateTime would be preferred because it includes additional information that clients could ignore if they don't need it. A server would be motivated to support dateTime not just date to preserve this simple interoperability.

> Expand oslc:valueType allowed values
> ------------------------------------
>                 Key: OSLCCORE-58
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-58
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: ian green
>            Assignee: James Amsden
>            Priority: Minor
> OSLC 2.0 defines the permitted values of oslc:valueType.  xsd:date is not one of them.  I've worked on one application that needed Date (not DateTime, which is permitted).  There is no suitable expression of a date as a dateTime, leading to a lack of expressiveness in OSLC shapes. 
> At the least, I should like to see xsd:dateTime being a permitted value in 3.0

This message was sent by Atlassian JIRA

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