Manu Sporny: Andy stopped working on the processor about 6 months ago because the spec was in too much flux. Tristan is working on getting it in shape in the near future
Manu Sporny: Working on the JSON-LD normalization now. Should be in good shape for a Java implementation in the next few months
Sandro Hawke: Working on some RDF issues in patch, such as when literals match case, etc. We were losing information such that triples don't match themselves often. example in email.
... Challenge with JSON being underspecified in numbers, different parsers have different parsing mechanisms.
... Basically, we might as well convert all native number types to json numbers
... don't convert decimal as most people use it to flag they care about exact precision
Manu Sporny: we had a lot of conversations regarding round-tripping with json-ld
... idea of round tripping issues is well known. Don't use use datatypes flag in order to ensure proper data round-tripping.
Sandro Hawke: add editorial comment to highlight the warning about round-tripping data issues.
Manu Sporny: there are some comments, but they could be highlighted better. We need to be careful to not to overly restrict data conversion 32/64 bit conversions, etc.
Sandro Hawke: don't pass around json-ld with native numbers unless you really don't care about your integrity
Manu Sporny: we tried to be specific in guidance. It needs to be added to the spec. This situation is very application specific
Manu Sporny: when data is published on the web today many assume that machine is 32bit capable.
Manu Sporny: most web developers won't convert numbers by converting to int, etc. and marking it with the xml type
Sandro Hawke: if you use native forms then clients may get the wrong data, should use expanded form.
Paul Kuykendall: I do think it's important that we say something in the spec, it might get lost - we're doing banking/financial apps - datatypes are very important wrt. numbers. [scribe assist by Manu Sporny]
Paul Kuykendall: It'll be good for our data consumers to know that this is an issue. [scribe assist by Manu Sporny]
Sandro Hawke: 2 parts of proposal. first part is editorial. Use native types is "do what I mean, but I accept errors"
... turn them into native numbers.
Sandro Hawke: the other part would be it alwas comes back as a double
Gregg Kellogg: I wonder if the flag is in the wrong place
Gregg Kellogg: perhaps there should be an expansion flag such that when we expand we turn all numeric data types into ? data types so that the consumers can choose how data is handled
Sandro Hawke: I like that
Gregg Kellogg: it is possible to use numerical representation and not loose type/precision information on conversion.
Manu Sporny: I have a concern about if it is round-tripable between rdf->jsonld->rdf
... you will loose information when transforming back and forth to json-ld
Sandro Hawke: if you don't want to lose info, don't use native
Manu Sporny: you never lose type information if you round-trip.
Gregg Kellogg: you can do a transformation and retain the type
... the precision could be changed, but the type is retained
... rdf - json is always using expanded form
... only on compaction will the type information be lost
Manu Sporny: I don't like that we lose type information between different types. It's a non-starter
Sandro Hawke: Wait, I thought you were saying that type information is preserved, isn't that what I'm proposing?
Manu Sporny: What I mean is that it is possible for the developers to better manage type conversion with the current approach. Markus' changes lose some of that fidelity.
Gregg Kellogg: add option so that the developer can choose if string representation or native form is used via an option flag if the types match.
... current spec has converting to string that are missing the data type.
Manu Sporny: we need to discuss this more with Markus and Dave on the call to talk about the changes being made. The changes have cascading effects
Manu Sporny: if we do make this change it would have a non-trivial change forcing another last-call
Gregg Kellogg: we haven't already entered 2nd last call
Manu Sporny: we can add an additional at-risk marker to keep us from having to enter a 3rd last call
Gregg Kellogg: I'll make sure it is brought up
Manu Sporny: need to mark it as "needs community input"
Sandro Hawke: I haven't seen that reference, but it makes sense. please look for that reference
Manu Sporny: We will try and fix these issues and add an issue marker highlighting the issue, and bring it up at the RDF working group
Sandro Hawke: we many need to refer to a different spec regarding futures - the DOM WHATWG one might change.
Sandro Hawke: hard requirement is to refer to stable things. it is hard to argue that the "living spec" is stable
... not saying we change the reference, but change how we use the reference
Manu Sporny: We don't actually reference the Futures spec directly. We only use the Future concept in our spec, not the API itself.
Sandro Hawke: if they change Futures, then every piece of software using futures would be broken and have to change
Manu Sporny: Being pedantic, but the spec wouldn't change, just the implementation.
Sandro Hawke: The director probably won't be okay with that. You shouldn't build on specs that are not stable
... We have to hard-code it with the current view of futures so that if it changes, we use the old version of futures
Manu Sporny: adding two issues to the spec and will publish next tuesday
... that gives us the chance to avoid al 3rd last-call
PROPOSAL: Add issue markers to the 2nd Last Call for JSON-LD Algorithms and API to warn about how the useNativeTypes flag and algorithm might change, and to also warn about the details of referencing the DOM-WHATWG spec wrt. Futures may change.
Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Sandro Hawke: +1
Niklas Lindström: +1
Stian Soiland-Reyes: +1
RESOLUTION: Add issue markers to the 2nd Last Call for JSON-LD Algorithms and API to warn about how the useNativeTypes flag and algorithm might change, and to also warn about the details of referencing the DOM-WHATWG spec wrt. Futures may change.
Gregg Kellogg: I think this should include how the useNativeType flag impacts the misuse of type conversion.
Topic: RDF-ISSUE-128: Mandatory profiles
Manu Sporny: Peter Ansell is asking us to make certain profiles mandatory on the server and client. He is saying that this is an inter-operability issue, which it is. We also can't force people into interop, and we do want people to be able to dip their toes into JSON-LD w/o being hit over the head by a requirement like this.
Manu Sporny: There is a thought that Peter might have missed the fact that we can't force people to do things they don't want to do by requiring a certain set of operations.
... if we require expanded, flattened, and compacted, then we increase the burden of server developers such that they may not want to implement the spec
Manu Sporny: we don't want the community to come along and say you're doing it wrong by not supporting everything in the spec
... there are good intentions but it could hinder large corporations from dipping their toes into json-ld
... it hurts incremental conformance of the spec
Gregg Kellogg: the proposal uses should instead of must
Paul Kuykendall: I think it's important that profiles are not mandatory - we're just implementing just enough to get us going. At this point, we don't need mandatory profiles. We'd like to be able to say we're using JSON-LD in our marketing docs, but at this point, we don't have the need to do anything more than expand (we don't support compact / flattened). Having that club out there would be a... [scribe assist by Manu Sporny]
Manu Sporny: ...detriment to us.
Paul Kuykendall: We intend to use the other formats, but at this point, we're trying to just get it done. [scribe assist by Manu Sporny]
Paul Kuykendall: While expand was a pretty big undertaking, compact and flatten really add a lot of extra overhead that doesn't buy us any real business value. It will in the future, but right now it doesn't provide us anything. Having that club out there wouldn't be good to us. [scribe assist by Manu Sporny]
Manu Sporny: what Paul just said is the same feedback as what the we've gotten from larger companies in private
... 'should' is fine verbiage rather than 'must' for implementation of spec
Gregg Kellogg: I think that the server is supposed to respond back with an error if you don't specify */* at the end...
Manu Sporny: if we're in a case where Apache and Express don't follow the spec, then there is a bigger disconnect.
Gregg Kellogg: question is, can a server respond with any time, even if it doesn't match what's in the ACCEPT header.
Gregg Kellogg: … This includes type parameters, needs research.
Niklas Lindström: it sounds like we're restating the rules of content negotiiation
Stian Soiland-Reyes: I don't think you need to do 406 if it's just the profile parameter that can't be satisfied (it might be satisfied, the server just don't know that)
Manu Sporny: we need to make sure we're not duplicating spec text