Re: Resolutions for features at risk

On 05/31/2013 05:41 PM, Markus Lanthaler wrote:
> * Feature at Risk 2: Reverse properties
> We have 6 implementations supporting reverse properties, thus
>
> PROPOSAL: Support reverse properties in JSON-LD 1.0.

+1

> * Feature at Risk 3: Allow blank nodes to be used as graph name or property
> We discussed this several times and always came to the same conclusion. I
> think we also had a resolution about that from the RDF WG group but wasn't
> able to find it.
> In the meantime the RDF WG decided to allow bnodes as graph names as well,
> but the last word may not be spoken yet on that decision. Nevertheless:
>
> PROPOSAL: Allow blank nodes to be used as graph names or properties in
> JSON-LD 1.0.

+1

> * Feature at Risk 7: Conversion to/from JSON Native Types
> Currently we convert xsd:integer, xsd:double, and xsd:boolean to native
> types and vice-versa. It may be more practical to convert all numeric types
> to JSON native types and all JSON numbers to xsd:doubles. The only exception
> that I think would make sense is xsd:decimal as in practice that is only
> used if precision matters, i.e., no rounding should occur.
> It is worth nothing that JSON-LD the data format does not suffer from
> rounding errors or range limits. The problem arises when such values are
> parsed by off-the-shelf JSON parsers and used in applications.
>
> Sandro suggested to leave this feature at risk throughout CR in the last RDF
> WG telecon. In any case, here are some proposals for discussion:
>
> 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)? 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. 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.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 3 June 2013 16:02:23 UTC