XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Deferred
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: Core
    • Labels:
      None
    • Proposal:
      Hide

      XX add xsd:date as a permitted value of oslc:valueType, in OSLC Core 3.0 XX

      There are three possible approaches to resolving this issue:
      1. Defer it and leave the literal types as they were defined in OSLC 2.0.
      2. Introduce a few new select literal types such as xsd:date, xsd:duration, and possibly rdf:langString
      3. Open the specification to any rdf or xsd literal type.

      3. was determined to require significant study to see what compatibility and interoperability issues it might introduce.

      2. was hard to justify because if the current set is inadequate for some reason, it is not clear why adding a few more would be any different.

      1. The Core TC decided to defer this issue as there are practiced work arounds (e.g., use xsd:dateTime even if xsd:date is all that is needed), and see if this issue is raised during public review.

      Show
      XX add xsd:date as a permitted value of oslc:valueType, in OSLC Core 3.0 XX There are three possible approaches to resolving this issue: 1. Defer it and leave the literal types as they were defined in OSLC 2.0. 2. Introduce a few new select literal types such as xsd:date, xsd:duration, and possibly rdf:langString 3. Open the specification to any rdf or xsd literal type. 3. was determined to require significant study to see what compatibility and interoperability issues it might introduce. 2. was hard to justify because if the current set is inadequate for some reason, it is not clear why adding a few more would be any different. 1. The Core TC decided to defer this issue as there are practiced work arounds (e.g., use xsd:dateTime even if xsd:date is all that is needed), and see if this issue is raised during public review.
    • Resolution:
      Hide

      The TC decided to defer this issue.

      Show
      The TC decided to defer this issue.

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              jamsden James Amsden
              Reporter:
              igreen ian green
            • Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: