[OASIS Issue Tracker] (OSLCCORE-58) Expand oslc:valueType allowed values

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

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

Nick Crossley commented on OSLCCORE-58:
---------------------------------------

However, describing a property as xsd:dateTime would give the wrong hints to a user interface when just a date was required.

There are bigger problems with other missing types - such as duration; a duration cannot be represented correctly as a date&time.

However, expanding oslc:valueType to allow arbitrary XSD data types is not necessarily a good idea - it might encourage too much use of subtypes where the current general types are probably better (xsd:int vs. xsd:integer).

On compatibility, I do not agree with the example "Extending OSLC primitive types could leading to OSLC v2.0 client breaking changes. For example, if an OSLC3 server happened to set a dcterm:created property to an xsd:date instead of xsd:dateTime ...". In the above case, if the OSLC domain in question defines dcterms:created as an xsd:dateTime, then that hypothetical OSLC 3 server that returned xsd:date would not be compliant. There is a compatibility issue, but it's quite subtle: a 2.0 client that parsed OSLC resource shapes would not understand an OSLC 3.0 shape that included a property with an oslc:valueType of xsd:duration (for example). There are not too many clients that parse shapes, so it is not clear how important this issue would be.

> 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
(v6.2.2#6258)