Dealing with unsupported literal value types

[Ian M Green11 <ian.m.green@uk.ibm.com>]

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?

As an aside, I
don't recall the design rationale that led to a closed set of data types,
which leads me to question that decision.  Should Core be less prescriptive
and leave the set of types open?

[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"

regards
   
    -ian

Ian Green
ian.m.green@uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU