Markus Lanthaler: I've looked at Gregg's algorithms - some of the stuff isn't properly spec'd, I think (don't know if I misunderstood some of the algorithms) [scribe assist by Manu Sporny]
Markus Lanthaler: There are some MUST statements in there that I don't think are necessary - we shouldn't duplicate normative spec text that is in the Syntax spec. [scribe assist by Manu Sporny]
Gregg Kellogg: I was attempting to replace a similar expression that said that it needed to raise an error - it acted as a hook for the API. "If the expectation was violated for 2.3, then raise this exception" [scribe assist by Manu Sporny]
Gregg Kellogg: If there is some way to rephrase that, then that would be fine if it's not normative text. [scribe assist by Manu Sporny]
Markus Lanthaler: This is the reason I didn't put stuff in to raise an error - it's still separated from the API, you just specifically enumerate the errors. [scribe assist by Manu Sporny]
Manu Sporny: it's a strange issue.. we want to make it easy for implementers to know where which errors should be raised, at the same time we want to separate the algorithms from the API
Gregg Kellogg: yeah, I didn't want to be explicit about an error. We could put something in there that points to the API. [scribe assist by Manu Sporny]
Manu Sporny: Gregg, from what I understand you took Markus' algorithms and tried to stick closer to the previous algorithms
Gregg Kellogg: Yeah.. expansion is more or less the same as Markus'
... context processing is quite different I would say.. for example I don't use a vocabRelative flag
... in IRI expansion e.g. I just said that there must not be a recursive term definition instead of exactly prescribing how to do it
... most changes are in Compaction
... and IRI Compaction continues to use Term Ranking with minor modifications
... I think having term ranking is simpler than having an inverse context
... it has been very difficult for me to understand the inverse context
Markus Lanthaler: We could simplify toRDF/fromRDF if we flatten the document first, and then we run the toRDF() algorithm on it. [scribe assist by Manu Sporny]
Gregg Kellogg: It's not too many steps, there might be some benefits to be gained by flattening. [scribe assist by Manu Sporny]
Gregg Kellogg: The only changes I needed to make was to make sure that when we were creating new bnodes that it continues using the same bnode generator that we used during the expansion phase. [scribe assist by Manu Sporny]
Manu Sporny: One of the things we almost definitely will put in the document is that the outcome of the algorithms is not going to change in LC but they might be modified to be simpler to read
Gregg Kellogg: currently I don't pass any of the flattening tests whereas I passed them all before
... I think that's mostly because I ignore property-less nodes
Gregg Kellogg: Markus did you change anything dramatically in the algorithm?
Markus Lanthaler: No, the only fundamental change was that now all graphs will be in the flattened output whereas before there was always just one
Manu Sporny: I went ahead and updated the spec with the error handler behavior
... Markus had some concerns about the complexity of the implementation, he thinks it goes a bit too far
... basically saying that non-fatal errors are just useful for validators/linters
... and that standardizing all possible issue codes is time consuming
Markus Lanthaler: We have two error handling mechanisms now, one for fatal errors, another for warnings and non-fatal errors. [scribe assist by Manu Sporny]
Markus Lanthaler: This is debug output - you can't really do anything useful with it. It might be nice to have the debug output, in the end, it wouldn't help you at all. The provided information is by no means enough to do anything useful with it. [scribe assist by Manu Sporny]
Markus Lanthaler: You can't track the message back to a specific location in the document. [scribe assist by Manu Sporny]
Markus Lanthaler: You can't implement a validator that highlights the parts that caused an error or a problem. I don't think it makes sense to specify it. It is potentially more harmful than helpful. [scribe assist by Manu Sporny]
Markus Lanthaler: I would propose that JsonLdOptions can be extended by concrete implementations - any implementation is free to add other debugging/monitoring functionality. [scribe assist by Manu Sporny]
Markus Lanthaler: We just specify where JSON-LD processors stop, and the error conditions for those. [scribe assist by Manu Sporny]
Manu Sporny: One of the issues I always had with JavaScript is that you don't get such information
... all you get is "processing failed"
... you don't know why it failed
... you don't get warnings - a lot of developers might want to have just that
... I also don't think we need to standardize every issue code
... we could let that organically grow. There wouldn't be that much of an implementation-burden for us as spec writers
... yes, we don't have line numbers etc. because JSON parsers don't provide that
... if the processor can get the line number somehow it should include that in the error
... so we should implementers not only say they can extend jsonLdOptions but also JsonLdProcessingIssue
... when we are developing systems we want to have this information
Gregg Kellogg: I think it's useful to have these things but it may get burdening when we need to enumerate all those errors
... that would allow use to include even more debugging information
Manu Sporny: would you be more happy with having more generic error codes for non-fatal errors
Discussion about whether non-fatal error reporting should be specified
Gregg Kellogg: I agree that having debugging output is useful but I also agree that it might not be necessary to put this into the spec
... for example in my Turtle processor it would have been much more difficult to include all the debugging information if the specs would have been very specific about it
Manu Sporny: Are you saying that we don't need to specify that callback?
Gregg Kellogg: In my case in Ruby, the more specific we get in the JSON-LD API the less similar my Ruby implementation looks to the API
... because it's just not done that way in Ruby
Manu Sporny: Right, one piece I updated in the spec is that this API is meant to be implemented in JavaScript
François Daoust: I think I share the view that Markus has
... but it doesn't really change the API
... it's just a property in JsonLdOptions
... but I think it that should be left to implementations
... I would drop the issueCallback property
Manu Sporny: gregg, you were one of the people who wanted to have multiple levels of issues - any thoughts?
Gregg Kellogg: I think we can leave it up to the implementations.
PROPOSAL: Accept the JSON-LD API spec text on error handling with a few modifications - remove the issueCallback mechanism from JsonLdOptions, remove severity fromJsonLdProcessorIssue, rename JsonLdProcessorIssue to JsonLdError.
Gregg Kellogg: +1
Manu Sporny: -0.3 (but I can live with it)
Markus Lanthaler: markus: +1
François Daoust: +1
RESOLUTION: Accept the JSON-LD API spec text on error handling with a few modifications - remove the issueCallback mechanism from JsonLdOptions, remove severity fromJsonLdProcessorIssue, rename JsonLdProcessorIssue to JsonLdError.
Topic: ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing
Manu Sporny: Markus' PROPOSAL 6 seem to have broad agreement: Rename JSON-LD syntax spec to "JSON-LD 1.0 - A JSON-based Serialization for Linked Data" and the API spec to "JSON-LD 1.0 Processing Algorithms and API" (without subtitle)
Manu Sporny: I'm not sure we are allowed to have no subtitle
François Daoust: I think we don't need to have one
... but rules might have changed
PROPOSAL: Rename JSON-LD syntax spec to "JSON-LD 1.0 - A JSON-based Serialization for Linked Data" and the API spec to "JSON-LD 1.0 Processing Algorithms and API (no subtitle)"
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
François Daoust: +1
RESOLUTION: Rename JSON-LD syntax spec to "JSON-LD 1.0 - A JSON-based Serialization for Linked Data" and the API spec to "JSON-LD 1.0 Processing Algorithms and API (no subtitle)"
Markus Lanthaler: could we have the short name json-ld instead of json-ld-syntax
Manu Sporny: yes, I think.. we would have to request it
Gregg Kellogg: I think we might also should change json-ld-api to something else as the emphasis is on the algorithms
Manu Sporny: This nomenclature discussion comes up every single time we try to put "IRI" into a specification. The problem is that the HTML5 spec uses URL, and Web developers are more familiar with URL instead of IRI. We are trying to build something useful for Web developers, so I think we should probably use 'URL'.
PROPOSAL: Include the text "Throughout this specification, the term 'URL' means IRI as defined in RFC3987. The reason we use URL is because it is more familiar to Web developers." and use the term URL everywhere in both specifications.
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
RESOLUTION: Include the text "Throughout this specification, the term 'URL' means IRI as defined in RFC3987. The reason we use URL is because it is more familiar to Web developers." and use the term URL everywhere in both specifications.
Markus Lanthaler: This is what we currently have in the spec:
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.
PROPOSAL: JSON-LD Processors do not modify URLs other than to translate between relative and absolute URLs. Specifically, they do not implement the URL processing rules as outlined in the HTML5 specification.
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Markus Lanthaler: +0
RESOLUTION: JSON-LD Processors do not modify URLs other than to translate between relative and absolute URLs. Specifically, they do not implement the URL processing rules as outlined in the HTML5 specification.
Topic: ISSUE-207: Handling of free-floating values in flattening/toRDF
Manu Sporny: the question is, how do we handle free-floating values?
Markus Lanthaler: so, what should happen for @graph: { "@id": "/test" }
Markus Lanthaler: @graph: { "@id": "/test", "doesntexpand": true } -- drop @id object?
Manu Sporny: yep, drop it [scribe assist by Manu Sporny]
PROPOSAL: Disallow free-floating values and IRIs in the JSON-LD Data model. If a free-floating value/IRI is detected during expansion, drop the value/IRI.
Markus Lanthaler: +1
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1
RESOLUTION: Disallow free-floating values and IRIs in the JSON-LD Data model. If a free-floating value/IRI is detected during expansion, drop the value/IRI.
Manu Sporny: I can't say this enough - you guys rock! Thank you for all of your great work - Markus, Gregg, Francois, Dave Longley, Dave Lehn, and all of the other folks that have contributed to the JSON-LD specs. We're in very good shape for Last Call, and the specs are in very good shape overall thanks to each of your hard work! Can't emphasize that enough. [scribe assist by Manu Sporny]