Open BigBlueHat opened 5 years ago
While reading w3c/pub-manifest#65 I tested the following JSON-LD in the playground:
{ "@context": { "name": { "@id": "http://example.com/name", "@type": "xsd:string" } }, "name": true }
This resulted in this unexpected (by me) expanded form:
[ { "http://example.com/name": [ { "@type": "xsd:string", "@value": true } ] } ]
Obviously...that's incorrect and I'd expected a warning, error, or (perhaps) type coercion.
Not incorrect, but are you suggesting that we should build in knowledge of the "xsd" so we know that it's not intended as an IRI scheme?
Reshaping it a bit, I added a
@language
tag, and that did throw a more expected error:{ "@context": { "name": { "@id": "http://example.com/name", "@type": "xsd:string" } }, "name": { "@language": "en", "@value": true } }
Ask here is to see if we could make this more obvious. 😄
The purpose of the @type
in the term definition is to know how to interpret string values. In this case, it's a value object, so the @type
definition does not come into play.
(Sorry, this isn't about the xsd
prefix, but about the asymmetry of handling value coercion).
Typically, if we see values that are native JSON values (true
, ...), the algorithms just leave them alone. If we were not to assign the @type
to the value object, we would be out-of-spec with 1.0, which is explicit about doing this.
Perhaps adding something that would make a native value along with @type
in a value object, or in coercion, an error, we could get away with it, but again are in danger of invalidating JSON-LD 1.0 content.
So, I'm probably wanting the xsd:string
(and friends) to be more "magic" than it is currently. And perhaps it's not JSON-LD's job to verify data--just to expand it.
The thinking is that the following expanded form JSON would be considered invalid by any one implementing a spec or code--see https://github.com/w3c/pub-manifest/issues/65 for a specific scenario and discussion:
[
{
"http://example.com/name": [
{
"@type": "xsd:string",
"@value": true
}
]
}
]
The result of the lack of this in JSON-LD means that something else (often JSON Schema) is needed to do actual value/content validation. Is/was that the expected scenario? If that's the case, then explaining this is certainly needed for the Best Practices. /cc @ajs6f
Also, I'm guessing the xsd:
prefix is the only one of it's kind?--i.e. CURIE's that don't expand?
This issue was discussed in a meeting.
RESOLVED: Transfer w3c/json-ld-syntax#257 to best practices document
@context.
I think we can address this, but IIUC I'm not sure we need to say much more than "JSON-LD contains no internal mechanism for data validation. You have to supply that yourself." (modulo better wording)
Or @BigBlueHat , are you thinking of a core commitment we could be seen as letting down?
Or @BigBlueHat , are you thinking of a core commitment we could be seen as letting down?
Not a core commitment, but a frequently misplaced expectation. 😕 We can certainly call it out with something as simple as you describe, so I'll take a crack at that shortly.
@type
in the context. Use Framing and @default
(note that 1.0 did not allow @default for @type
)This issue was discussed in a meeting.
@type
sometimes does not behave as anticipated, even by bigbluehat@type
@default
in framing, when applied to @type.
@type
in the context. Use Framing and @default
(note that 1.0 did not allow @default
for @type)
While reading https://github.com/w3c/pub-manifest/issues/65 I tested the following JSON-LD in the playground:
This resulted in this unexpected (by me) expanded form:
Obviously...that's incorrect and I'd expected a warning, error, or (perhaps) type coercion.
Reshaping it a bit, I added a
@language
tag, and that did throw a more expected error:Ask here is to see if we could make this more obvious. 😄