[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=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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]