Re: sandro's review of json-ld-api

On 04/01/2013 03:01 PM, Markus Lanthaler wrote:
> Sandro, I've addresses the remaining issue you raised in your API spec
> review (see below). There are some things for which I didn't make a change,
> these are the things for which I asked for clarification in my last mail:
>
>    http://lists.w3.org/Archives/Public/public-rdf-wg/2013Mar/0287.html
>
> but it's probably easier to read at:
>
>    https://github.com/json-ld/json-ld.org/issues/234#issuecomment-15637714
>
> To get a diff for the commits I referenced in the comments below, just
> append the commit hash to the following URL:
>
>    https://github.com/json-ld/json-ld.org/commit/

How do I see the current spec...?   Preferably a frozen copy of it?

     -- Sandro

>
>
>
>> General Solution   (many times in the document)
>>
>> This term really threw me off, and doesn't seem right.   I think you
>> mean "Algorithm Overview" or "Algorithm Summary" or "Algorithm
>> Sketch".   Since it's always in an Algorithm section it could just
>> be "Sketch" or "Informal Summary".
> Fixed in d379fc2231fd1c3097b9d9f3b75a820b484efff5
>
>
>>> 3) In Conformance it says:
>>> This specification does not define how JSON-LD Implementations or
>>> Processors handle non-conforming input documents. This implies
>>> that JSON-LD Implementations or Processors MUST NOT attempt to
>>> correct malformed IRIs or language tags; however, they MAY issue
>>> validation warnings.
>> But, um, no, I don't think it does imply that.   If you don't say
>> how systems are to handle non-conforming input documents, then they
>> are free to handle it however they want, including by "repairing"
>> them in various ways.    If you're forbidding repairing IRIs or
>> language tags, then you're very much saying how systems have to
>> handle non-conforming input documents.      Which is it?
>
> Fixed in afb28264889d8266af585ce9b1d95523a331bcd0
>
>
>>> When data such as decimals need to be normalized, JSON-LD authors
>>> should not use values that are going to undergo automatic
>>> conversion. This is due to the lossy nature of xsd:double values.
>> I can't quite make sense of this.
> Remove in cbcd28960b2014dc45e4e98fb192278c99cd47ff - I don't think it's the
> job of this job to warn developers about such things.
>
>
>> 2) The conformance classes don't seem quite right. Every "JSON-LD
>> Implementation" has to implement conversion to and from RDF? I don't
>> really see a need to force them to do that (and I don't think they
>> will). Every "JSON-LD Processor" has to be written in JavaScript (or
>> some other language for which a WebIDL binding currently exists)?
>> That seems like a rather counter-intuitive use of the word
>> "processor"....
>>
>> Suggested fix:
>> A JSON-LD Processor is a system which can perform the Expansion,
>> Compaction, and Flattening operations. JSON-LD Processors providing
>> interfaces to languages for which W3C Recommended WebIDL bindings
>> exist ?MUST?SHOULD? use the API defined in this specification [etc].
>> A JSON-LD Processor With RDF Conversion is a JSON-LD Processor that
>> can also perform Conversion to RDF and Conversion from RDF.
> I fixed this in 72eca20e3e1382f85ed79ce68c09c450e4092717. Instead of adding
> a "JSON-LD Processor With RDF Conversion" I decided to introduce a separate
> product class, an "JSON-LD-RDF Converter" which "s a system that can perform
> Conversion to RDF and Conversion from RDF".
>
>
>>> 1) I'm concerned about the restriction on lists of lists.     I
>>> don't like the idea that some RDF graphs can't be serialized in
>>> JSON-LD.      I could see how compacting them could be hard
>>> (nested type information...?) but why not at least allow them in
>>> expanded form?
>> This restriction exists only if you want to use arrays to represent
>> the list (@list). It does not exist if you represent the list as a
>> linked list (I assume that's what you mean by expanded form), i.e.,
>> a set of blank nodes with first/rest properties. We have been
>> discussing (ISSUE #75) whether we allow identifiers for @list but
>> decided to not do that. So currently the only way around that
>> restriction is really to represent the list as a set of interlinked
>> node objects.
>>
>>> Suggested fix: let's at least make this restriction At Risk, add
>>> some test cases, and see how implementers fare with it.   We don't
>>> even need to modify the algorithms in the spec; we can just say
>>> "In the interest of space and simplicity, the steps necessary for
>>> handling lists of lists have been omitted.    Such lists and their
>>> elements must, recursively, be handled like other lists.   NOTE
>>> this is an AT RISK feature.  The Working Group might either
>>> require handling of lists-of-lists or forbid them in JSON-LD.
>>> Implementers please send reports of whether you are able to
>>> implement handling for lists-of-lists or would instead request
>>> such structures be disallowed."
> Fixed in add6b8ce63fd9763260ca8cf6d4801299302a343. I've also added the
> following sentence:
>
> "Lists of lists can, however, not be represented in JSON-LD using @list;
> they have to be represented as a set of interlinked node objects using RDF's
> rdf:first and rdf:rest properties."
>
>
>>>> Issue 217
>>>> RDF does not currently allow a blank node identifier to be used as a
> graph name.
>>> This shouldn't be an issue any more should it? How about make it a
>>> NOTE, and add another line about how JSON-LD Processors can
>>> convert such blank nodes to IRIs as per
>>> http://www.w3.org/TR/rdf11-concepts/#section-skolemization if they
>>> need to produce valid RDF.
>>   Would be fine for me. The reason there's still an issue marker in there
> is to avoid a potential second last call. Thoughts?
>
> I think in order to avoid a potential second last call this has to be an
> issue marker or am I wrong? I've changed the text to
>
> in 7378aae65ad7387449f6abafe41c53e0d2629048
>
>
> Please let me know if this addressed you concerns of if there are some
> remaining things you want to have fixed before LC.
>
>
> Thanks again,
> Markus
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Monday, 1 April 2013 19:14:57 UTC