RE: Resolutions for features at risk

On Sent: Monday, June 03, 2013 6:02 PM, Dave Longley wrote:
> On 05/31/2013 05:41 PM, Markus Lanthaler wrote:
> > PROPOSAL a: Keep conversion to/from native types as-is
> > PROPOSAL b: Convert all of XSD's numeric types to native numbers and
> > xsd:booleans to true/false. Convert native numbers back to xsd:double
> > PROPOSAL c: Same as proposal b with the exception of not converting
> > xsd:decimal
> > PROPOSAL d: Keep conversion to/from native-types as-is but limit it
> > to numbers in the 32bit/64bit range
> 
> This definitely needs more discussion. I have a particular concern
> about
> proposals 'b' and 'c' -- would processors now need to know how to
> properly convert native numbers to canonical lexical form for each xsd
> datatype (not just the non-ranged xsd:integer and xsd:double)?

No, just xsd:double since all native numbers would be converted to
xsd:double-typed literals.


> If a native number has a datatype of xsd:short in the @context, does
> the processor need to ensure that the conversion handles overflow?
> There are similar questions for unsigned numbers.

The type from the context doesn't apply in that case. It just applies to
strings. That's the same as we currently do.


> I think we'll need to say
> exactly what a processor must do in these cases. We can only attach a
> datatype of xsd:double (and do the specific string conversion in the
> spec) when no other datatype has been given in the @context.

As said above, type coercion doesn't apply to numbers or booleans.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 3 June 2013 19:53:40 UTC