New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensions: JSON Schema Validation #577

Open
canweriotnow opened this Issue Jan 6, 2015 · 33 comments

Comments

Projects
None yet
9 participants
@canweriotnow
Contributor

canweriotnow commented Jan 6, 2015

I get the point of not allowing LRSs to reject statements based on non-recognized extensions, but it seems to me that this is akin to saying "take this stuff that is (to you) useless garbage and store it because I say so."

Requiring extensions to carry a JSON Schema would allow LRSs to determine how to utilize the information contained within and make the extension useful to any receiving LRS.

Yes, yes, I know, breaking change, 2.0.

I think the best possible implementation would involve using JSON-LD, but that's probably its own issue.

EDIT:

I retitled the issue b/c I think the JSON-LD stuff was clouding the issue... the proposal here was simply to allow LRSs to validate extensions that carried a JSON Schema (and reject broken ones) as a patch issue, with an eye toward (perhaps) requiring schemas and using JSON-LD in extensions in a future version (2.0?)

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Jan 6, 2015

Contributor

I'm interested to learn more about JSON-LD as @aaronesilvers also mentioned this recently. I did have a very quick look on wikipedia and couldn't see how it would convey enough information to be useful but i'd love to hear from somebody more knowledgable on the subject.

Would somebody be willing to do a short presentation on one of the calls?

Allowing or even encouraging (rather than requiring) extensions to make use of JSON-LD might be a something that could be done in 1.0.3 or 1.1.0. So long as JSON-LD is valid JSON I guess it's already allowed in extensions. It could also be required by particular recipes outside the spec.

Contributor

garemoko commented Jan 6, 2015

I'm interested to learn more about JSON-LD as @aaronesilvers also mentioned this recently. I did have a very quick look on wikipedia and couldn't see how it would convey enough information to be useful but i'd love to hear from somebody more knowledgable on the subject.

Would somebody be willing to do a short presentation on one of the calls?

Allowing or even encouraging (rather than requiring) extensions to make use of JSON-LD might be a something that could be done in 1.0.3 or 1.1.0. So long as JSON-LD is valid JSON I guess it's already allowed in extensions. It could also be required by particular recipes outside the spec.

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Jan 6, 2015

Contributor

@garemoko this is something that was recently adopted for the OBI 1.1 spec, I think I have some slides from one of those calls that explains how it works for Open Badges, I'll try to find them and either link or send out to the list.

I'm pretty sure the "official" stance on JSON-LD is that it has its own MIME type, but as it doesn't "break" valid JSON to the best of my knowledge, I don't think it should be an issue? I'll follow up soon. It would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps with the possibility of a MUST in 2.0.

Contributor

canweriotnow commented Jan 6, 2015

@garemoko this is something that was recently adopted for the OBI 1.1 spec, I think I have some slides from one of those calls that explains how it works for Open Badges, I'll try to find them and either link or send out to the list.

I'm pretty sure the "official" stance on JSON-LD is that it has its own MIME type, but as it doesn't "break" valid JSON to the best of my knowledge, I don't think it should be an issue? I'll follow up soon. It would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps with the possibility of a MUST in 2.0.

@fugu13

This comment has been minimized.

Show comment
Hide comment
@fugu13

fugu13 Jan 6, 2015

Contributor

The issue I have with JSON Schema is that JSON Schema validators are all
over the place with level of support for many parts of the standard, which
makes it hard to be sure one's schema is fully right. Additionally, I think
JSON-LD is a much better candidate for machine-described rich JSON content.
It's still a good idea to publish a JSON Schema when there are more
complicated validation needs, but it doesn't make sense to require
extensions be validated against schemas for acceptance.

What's more, LRSs can support JSON-LD without breaking xAPI. It would be
breaking to add the JSON-LD attributes and add the mime-type (both must be
done to serve JSON-LD content directly), but the JSON-LD standard allows
for providing a JSON-LD context via a Link header, which is entirely
allowed. All it would take is one place publishing a good JSON-LD context
that everyone could then link to.

Additionally, extension authors could place a JSON-LD context directly into
extensions. I don't think we need to put that in the standard yet, but I'd
like to strongly encourage it.

Sincerely,
Russell

On Tue, Jan 6, 2015 at 10:58 AM, Jason Lewis notifications@github.com
wrote:

@garemoko https://github.com/garemoko this is something that was
recently adopted for the OBI 1.1 spec, I think I have some slides from one
of those calls that explains how it works for Open Badges, I'll try to find
them and either link or send out to the list.

I'm pretty sure the "official" stance on JSON-LD is that it has its own
MIME type, but as it doesn't "break" valid JSON to the best of my
knowledge, I don't think it should be an issue? I'll follow up soon. It
would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps
with the possibility of a MUST in 2.0.


Reply to this email directly or view it on GitHub
#577 (comment).

Contributor

fugu13 commented Jan 6, 2015

The issue I have with JSON Schema is that JSON Schema validators are all
over the place with level of support for many parts of the standard, which
makes it hard to be sure one's schema is fully right. Additionally, I think
JSON-LD is a much better candidate for machine-described rich JSON content.
It's still a good idea to publish a JSON Schema when there are more
complicated validation needs, but it doesn't make sense to require
extensions be validated against schemas for acceptance.

What's more, LRSs can support JSON-LD without breaking xAPI. It would be
breaking to add the JSON-LD attributes and add the mime-type (both must be
done to serve JSON-LD content directly), but the JSON-LD standard allows
for providing a JSON-LD context via a Link header, which is entirely
allowed. All it would take is one place publishing a good JSON-LD context
that everyone could then link to.

Additionally, extension authors could place a JSON-LD context directly into
extensions. I don't think we need to put that in the standard yet, but I'd
like to strongly encourage it.

Sincerely,
Russell

On Tue, Jan 6, 2015 at 10:58 AM, Jason Lewis notifications@github.com
wrote:

@garemoko https://github.com/garemoko this is something that was
recently adopted for the OBI 1.1 spec, I think I have some slides from one
of those calls that explains how it works for Open Badges, I'll try to find
them and either link or send out to the list.

I'm pretty sure the "official" stance on JSON-LD is that it has its own
MIME type, but as it doesn't "break" valid JSON to the best of my
knowledge, I don't think it should be an issue? I'll follow up soon. It
would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps
with the possibility of a MUST in 2.0.


Reply to this email directly or view it on GitHub
#577 (comment).

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Jan 6, 2015

Contributor

@fugu13 @garemoko Here's Nate's presentation for using JSON-LD in OBI extensions, as promised:

Open Badges Standard Extension Proposal

I agree that JSON Schema can be overkill in some places, but I think the OBI folks came up with a good balance. It's not isometrically applicable to xAPI, but I think LD could not only clear up extensions, but solve some problems in other areas. And again, since it's valid JSON, it wouldn't break compatibility, earlier versions could safely ignore it.

Contributor

canweriotnow commented Jan 6, 2015

@fugu13 @garemoko Here's Nate's presentation for using JSON-LD in OBI extensions, as promised:

Open Badges Standard Extension Proposal

I agree that JSON Schema can be overkill in some places, but I think the OBI folks came up with a good balance. It's not isometrically applicable to xAPI, but I think LD could not only clear up extensions, but solve some problems in other areas. And again, since it's valid JSON, it wouldn't break compatibility, earlier versions could safely ignore it.

@aaronesilvers

This comment has been minimized.

Show comment
Hide comment
@aaronesilvers

aaronesilvers Jan 6, 2015

Contributor

I'd like to +1 any exploration/move towards JSON-LD. It plays nicely with
RDF. It works really well with OWL (web ontology language... let's not get
into why it's not WOL instead of OWL), which if we're serious about
registries, taxonomies, ontologies... well, you get the picture there. It
enables more potential for what little it may potentially add.

-a-


#mobile

Aaron E. Silvers | MakingBetter http://makingbetter.us/
857.34.BEARD | @aaronesilvers http://twitter.com/aaronesilvers

Let’s meet! Pick a time https://doodle.com/makingbetter.

On Tue, Jan 6, 2015 at 3:03 PM, Jason Lewis notifications@github.com
wrote:

@fugu13 https://github.com/fugu13 @garemoko
https://github.com/garemoko Here's Nate's presentation for using
JSON-LD in OBI extensions, as promised:

Open Badges Standard Extension Proposal
https://docs.google.com/presentation/d/1dWMU2gdnfjBPRJTCcCDOJrs0xSgCwNc-IOUdjq9gRmw/edit?usp=sharing

I agree that JSON Schema can be overkill in some places, but I think the
OBI folks came up with a good balance. It's not isometrically applicable to
xAPI, but I think LD could not only clear up extensions, but solve some
problems in other areas. And again, since it's valid JSON, it wouldn't
break compatibility, earlier versions could safely ignore it.


Reply to this email directly or view it on GitHub
#577 (comment).

Contributor

aaronesilvers commented Jan 6, 2015

I'd like to +1 any exploration/move towards JSON-LD. It plays nicely with
RDF. It works really well with OWL (web ontology language... let's not get
into why it's not WOL instead of OWL), which if we're serious about
registries, taxonomies, ontologies... well, you get the picture there. It
enables more potential for what little it may potentially add.

-a-


#mobile

Aaron E. Silvers | MakingBetter http://makingbetter.us/
857.34.BEARD | @aaronesilvers http://twitter.com/aaronesilvers

Let’s meet! Pick a time https://doodle.com/makingbetter.

On Tue, Jan 6, 2015 at 3:03 PM, Jason Lewis notifications@github.com
wrote:

@fugu13 https://github.com/fugu13 @garemoko
https://github.com/garemoko Here's Nate's presentation for using
JSON-LD in OBI extensions, as promised:

Open Badges Standard Extension Proposal
https://docs.google.com/presentation/d/1dWMU2gdnfjBPRJTCcCDOJrs0xSgCwNc-IOUdjq9gRmw/edit?usp=sharing

I agree that JSON Schema can be overkill in some places, but I think the
OBI folks came up with a good balance. It's not isometrically applicable to
xAPI, but I think LD could not only clear up extensions, but solve some
problems in other areas. And again, since it's valid JSON, it wouldn't
break compatibility, earlier versions could safely ignore it.


Reply to this email directly or view it on GitHub
#577 (comment).

@andyjohnson andyjohnson added the major label Jan 7, 2015

@ryansmith94

This comment has been minimized.

Show comment
Hide comment
@ryansmith94

ryansmith94 Jan 7, 2015

Contributor

+1 for JSON-LD, not something I've read a lot of, but looks like a solution to things that have been bugging me for a long time with JSON.

Contributor

ryansmith94 commented Jan 7, 2015

+1 for JSON-LD, not something I've read a lot of, but looks like a solution to things that have been bugging me for a long time with JSON.

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Jan 7, 2015

Contributor

@andyjohnson please also label this at patch and minor as I think there may be things we can do at those stages too.

Contributor

garemoko commented Jan 7, 2015

@andyjohnson please also label this at patch and minor as I think there may be things we can do at those stages too.

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Jan 7, 2015

Contributor

@garemoko @andyjohnson I agree this should be patch/minor. I would suggest (for the patch version of this):

  • SHOULD use JSON-LD for Extensions
  • MAY include a JSON Schema URI in JSON-LD metadata

Or something of the like. I changed the issue title to remove "require" so we can hopefully get this out of "major".

Contributor

canweriotnow commented Jan 7, 2015

@garemoko @andyjohnson I agree this should be patch/minor. I would suggest (for the patch version of this):

  • SHOULD use JSON-LD for Extensions
  • MAY include a JSON Schema URI in JSON-LD metadata

Or something of the like. I changed the issue title to remove "require" so we can hopefully get this out of "major".

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Jan 7, 2015

Contributor

@aaronesilvers The OWLs are not what they seem.
tp

As far as the letter ordering... why is "Universal Coordinated Time" UTC? Just blame the French.

Contributor

canweriotnow commented Jan 7, 2015

@aaronesilvers The OWLs are not what they seem.
tp

As far as the letter ordering... why is "Universal Coordinated Time" UTC? Just blame the French.

@canweriotnow canweriotnow changed the title from Extensions: Require JSON Schema to Extensions: JSON-LD and JSON Schema Jan 7, 2015

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik Feb 6, 2015

Howdy,

In W3C Social WG we work on Activity Streams 2.0 and base it on JSON-LD!

As participant of mentioned Social WG, Social IG (plus Social IG Liaison TF) and Credentials CG, I would happily join one of you calls to discuss AS2.0 and JSON-LD 📞

BTW I also try to help with clarifying extension mechanism in Schema.org, improving schema.org/Action sub tree and aligning work on AS2.0 and Schema.org (all mentioned above use JSON-LD)

Cheers!

elf-pavlik commented Feb 6, 2015

Howdy,

In W3C Social WG we work on Activity Streams 2.0 and base it on JSON-LD!

As participant of mentioned Social WG, Social IG (plus Social IG Liaison TF) and Credentials CG, I would happily join one of you calls to discuss AS2.0 and JSON-LD 📞

BTW I also try to help with clarifying extension mechanism in Schema.org, improving schema.org/Action sub tree and aligning work on AS2.0 and Schema.org (all mentioned above use JSON-LD)

Cheers!

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Mar 10, 2015

Contributor

I'm still in favour of adding a patch label to this alongside the major label cc @andyjohnson

Contributor

garemoko commented Mar 10, 2015

I'm still in favour of adding a patch label to this alongside the major label cc @andyjohnson

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Mar 10, 2015

Contributor

@canweriotnow re "MAY include a JSON Schema URI in JSON-LD metadata" - can you give some more details either here, or on the forums, about what this means? An example would be good!

Contributor

garemoko commented Mar 10, 2015

@canweriotnow re "MAY include a JSON Schema URI in JSON-LD metadata" - can you give some more details either here, or on the forums, about what this means? An example would be good!

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko
Contributor

garemoko commented Mar 10, 2015

@andyjohnson andyjohnson added the patch label Mar 10, 2015

@fugu13

This comment has been minimized.

Show comment
Hide comment
@fugu13

fugu13 Mar 10, 2015

Contributor

I'm not sure what exactly he's referring to there; the way Open Badges includes a JSON schema URI is idiosyncratic and not based on any precedent (per the author of the concept). It uses an Open Badges specific namespace, too. If someone chooses to adopt a similar approach, they'll need to specify their own way (though it'd probably end up being similar to Open Badges' way).

I recommend we do not include any of this in the spec. It is entirely reasonable for these to proceed outside of the spec (there's nothing stopping anyone from doing them), and while they'd only be SHOULDs, incorporation of JSON-LD into the spec should be done in a more principled way rather than piecemeal.

Contributor

fugu13 commented Mar 10, 2015

I'm not sure what exactly he's referring to there; the way Open Badges includes a JSON schema URI is idiosyncratic and not based on any precedent (per the author of the concept). It uses an Open Badges specific namespace, too. If someone chooses to adopt a similar approach, they'll need to specify their own way (though it'd probably end up being similar to Open Badges' way).

I recommend we do not include any of this in the spec. It is entirely reasonable for these to proceed outside of the spec (there's nothing stopping anyone from doing them), and while they'd only be SHOULDs, incorporation of JSON-LD into the spec should be done in a more principled way rather than piecemeal.

@andyjohnson

This comment has been minimized.

Show comment
Hide comment
@andyjohnson

andyjohnson Nov 18, 2015

Contributor

Per the 11/18/2015 call, last chance to get anything changed for version 1.0.3. No changes currently planned as JSON-LD isn't quite a de facto standard(yet).

Contributor

andyjohnson commented Nov 18, 2015

Per the 11/18/2015 call, last chance to get anything changed for version 1.0.3. No changes currently planned as JSON-LD isn't quite a de facto standard(yet).

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Nov 18, 2015

JSON-LD isn't quite a de facto standard(yet).

That is wrong. JSON-LD is a real standard: http://www.w3.org/TR/json-ld/

akuckartz commented Nov 18, 2015

JSON-LD isn't quite a de facto standard(yet).

That is wrong. JSON-LD is a real standard: http://www.w3.org/TR/json-ld/

@fugu13

This comment has been minimized.

Show comment
Hide comment
@fugu13

fugu13 Nov 18, 2015

Contributor

Yeah, while I don't think it makes sense to include any language about using JSON-LD in extensions in xAPI at this point, since that's already entirely allowed and it wouldn't provide any non-custom semantics (though that'd be worth exploring in future versions of xAPI), JSON-LD is not just already a standard, but one seeing a lot of adoption, which a number of other standards are basing themselves on.

Contributor

fugu13 commented Nov 18, 2015

Yeah, while I don't think it makes sense to include any language about using JSON-LD in extensions in xAPI at this point, since that's already entirely allowed and it wouldn't provide any non-custom semantics (though that'd be worth exploring in future versions of xAPI), JSON-LD is not just already a standard, but one seeing a lot of adoption, which a number of other standards are basing themselves on.

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Nov 18, 2015

Contributor

@fugu13 it was the adoption question we briefly discussed on the call. Given that you are seeing a lot of adoption, is it worth recommending using json ld in this version?

Contributor

garemoko commented Nov 18, 2015

@fugu13 it was the adoption question we briefly discussed on the call. Given that you are seeing a lot of adoption, is it worth recommending using json ld in this version?

@fugu13

This comment has been minimized.

Show comment
Hide comment
@fugu13

fugu13 Nov 18, 2015

Contributor

I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.

But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.

Contributor

fugu13 commented Nov 18, 2015

I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.

But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.

@aaronesilvers

This comment has been minimized.

Show comment
Hide comment
@aaronesilvers

aaronesilvers Nov 20, 2015

Contributor

+1
The spec community can and should start a research activity around the use (even universal use) of JSON-LD so we can roll the findings into the spec, but I don't think we should just push this as a potentially breaking change to current practice without the drivers and clear value mapped for the changes to recognize who's doing what with the spec (like certification). 

Sent from Outlook

On Wed, Nov 18, 2015 at 1:13 PM -0800, "fugu13" notifications@github.com wrote:

I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.

But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.


Reply to this email directly or view it on GitHub.

Contributor

aaronesilvers commented Nov 20, 2015

+1
The spec community can and should start a research activity around the use (even universal use) of JSON-LD so we can roll the findings into the spec, but I don't think we should just push this as a potentially breaking change to current practice without the drivers and clear value mapped for the changes to recognize who's doing what with the spec (like certification). 

Sent from Outlook

On Wed, Nov 18, 2015 at 1:13 PM -0800, "fugu13" notifications@github.com wrote:

I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.

But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.


Reply to this email directly or view it on GitHub.

@jhaag75

This comment has been minimized.

Show comment
Hide comment
@jhaag75

jhaag75 Nov 20, 2015

Member

Russell has been a huge help in advising the vocab group on using linked data for xAPI vocabularies this past year and it is a good first step for us. We plan to push out a draft companion doc & primer next month for the spec community to review. This should help drive some of the practices in this direction, but modernizing the entire model of xAPI could be a much bigger undertaking than we realize. As Russell pointed out it isn't only about the statements.

Would the community like to see something like this initially funded?

ADL's FY16 BAA was just posted to Fed Biz Ops this week. The link to the BAA is: https://www.fbo.gov/notices/27450b5709d4d5c74091ceaffd9766c2. The solicitation number is: ADLBAA12001. Per the BAA, Quad Charts are requested to be submitted by 7 December 2015.

Member

jhaag75 commented Nov 20, 2015

Russell has been a huge help in advising the vocab group on using linked data for xAPI vocabularies this past year and it is a good first step for us. We plan to push out a draft companion doc & primer next month for the spec community to review. This should help drive some of the practices in this direction, but modernizing the entire model of xAPI could be a much bigger undertaking than we realize. As Russell pointed out it isn't only about the statements.

Would the community like to see something like this initially funded?

ADL's FY16 BAA was just posted to Fed Biz Ops this week. The link to the BAA is: https://www.fbo.gov/notices/27450b5709d4d5c74091ceaffd9766c2. The solicitation number is: ADLBAA12001. Per the BAA, Quad Charts are requested to be submitted by 7 December 2015.

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Nov 30, 2015

Contributor

Leaving JSON-LD to the side (for the moment), what I'd really like to see come out of this is the ability for LRSs that parse extensions that declare a JSON-Schema via their IRI identifier to reject Statements with invalid (per the schema) extensions. The standards-wrangling is a sideshow, IMHO.

But if I'm crafting an AP, such as (I dunno, a flight simulator, since we've done that before) which uses an extension to map the X/Y/Z coordinates of the plane, I need to be able to ensure that Cleetus the slack-jawed yokel isn't going to use the same IRI to send extension data about his possum soup recipe when I'm trying to analyze simulated flight recorder data. So some mechanism for separating flight data from possum soup data is desirable.

I'm only looking for a MAY or perhaps SHOULD in 1.0.3, obviously a MUST is a 2.0 issue; if other LRSs want to accept possum soup recipes in from APs claiming to be flight simulators, that's their business. I just want to be able to reject Statements telling me how to gut and season a possum when I'm looking for pitch, yaw, and roll.

Contributor

canweriotnow commented Nov 30, 2015

Leaving JSON-LD to the side (for the moment), what I'd really like to see come out of this is the ability for LRSs that parse extensions that declare a JSON-Schema via their IRI identifier to reject Statements with invalid (per the schema) extensions. The standards-wrangling is a sideshow, IMHO.

But if I'm crafting an AP, such as (I dunno, a flight simulator, since we've done that before) which uses an extension to map the X/Y/Z coordinates of the plane, I need to be able to ensure that Cleetus the slack-jawed yokel isn't going to use the same IRI to send extension data about his possum soup recipe when I'm trying to analyze simulated flight recorder data. So some mechanism for separating flight data from possum soup data is desirable.

I'm only looking for a MAY or perhaps SHOULD in 1.0.3, obviously a MUST is a 2.0 issue; if other LRSs want to accept possum soup recipes in from APs claiming to be flight simulators, that's their business. I just want to be able to reject Statements telling me how to gut and season a possum when I'm looking for pitch, yaw, and roll.

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Nov 30, 2015

Contributor

This is the part I think needs to be altered:

An LRS MUST NOT reject a Statement based on the values of the extensions map.

(From 4.1 Extensions)

An suggested alternate:

An Extension IRI MAY reference a JSON-Schema declaring acceptable format/values for the extension map.
An LRS MAY reject a Statement based on an invalid extension map IFF a Schema is declared.
An LRS MUST NOT reject a Statement based on the values of the extensions map if no Schema is available.

Contributor

canweriotnow commented Nov 30, 2015

This is the part I think needs to be altered:

An LRS MUST NOT reject a Statement based on the values of the extensions map.

(From 4.1 Extensions)

An suggested alternate:

An Extension IRI MAY reference a JSON-Schema declaring acceptable format/values for the extension map.
An LRS MAY reject a Statement based on an invalid extension map IFF a Schema is declared.
An LRS MUST NOT reject a Statement based on the values of the extensions map if no Schema is available.

@ryansmith94

This comment has been minimized.

Show comment
Hide comment
@ryansmith94

ryansmith94 Nov 30, 2015

Contributor

Seems reasonable @canweriotnow. Not looked into JSON-LD enough to know how to validate using the schemas, but I'm sure it's simple enough.

Contributor

ryansmith94 commented Nov 30, 2015

Seems reasonable @canweriotnow. Not looked into JSON-LD enough to know how to validate using the schemas, but I'm sure it's simple enough.

@jhaag75

This comment has been minimized.

Show comment
Hide comment
@jhaag75

jhaag75 Nov 30, 2015

Member

I think another point that is important in this is the practice of good IRI design and persistence. We plan to incorporate this in a draft companion spec for xAPI verbs,vocabs, etc. and update the draft guidance in this doc surrounding the creating of IRIs:
https://docs.google.com/document/d/1RavkVwdzWQNszMXs8DMEth0bayAZRGBWWlSYVJtnC7M/edit

Any thoughts on this guidance?

In regards to this proposed update for the core spec, I recommend we be consistent with either saying "JSON-LD" or "JSON Schema." They aren't quite the same thing and could lead to confusion or inconsistent implementations by the community.

http://json-schema.org/
http://json-ld.org/

Member

jhaag75 commented Nov 30, 2015

I think another point that is important in this is the practice of good IRI design and persistence. We plan to incorporate this in a draft companion spec for xAPI verbs,vocabs, etc. and update the draft guidance in this doc surrounding the creating of IRIs:
https://docs.google.com/document/d/1RavkVwdzWQNszMXs8DMEth0bayAZRGBWWlSYVJtnC7M/edit

Any thoughts on this guidance?

In regards to this proposed update for the core spec, I recommend we be consistent with either saying "JSON-LD" or "JSON Schema." They aren't quite the same thing and could lead to confusion or inconsistent implementations by the community.

http://json-schema.org/
http://json-ld.org/

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Nov 30, 2015

Contributor

@jhaag75 You're absolutely right - This should really be two issues, one for JSON-Schema validation and another for JSON-LD support. I'm going to edit to clarify that this issue is really about allowing JSON-Schema validation of extensions, not full JSON-LD support.

Contributor

canweriotnow commented Nov 30, 2015

@jhaag75 You're absolutely right - This should really be two issues, one for JSON-Schema validation and another for JSON-LD support. I'm going to edit to clarify that this issue is really about allowing JSON-Schema validation of extensions, not full JSON-LD support.

@canweriotnow canweriotnow changed the title from Extensions: JSON-LD and JSON Schema to Extensions: JSON Schema Validation Nov 30, 2015

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Nov 30, 2015

Contributor

@andyjohnson take a look at #577 (comment), I'd be happy to make it a PR if the language seems reasonable.

Contributor

canweriotnow commented Nov 30, 2015

@andyjohnson take a look at #577 (comment), I'd be happy to make it a PR if the language seems reasonable.

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Nov 30, 2015

Contributor

For 1.0.3 I worry that this is technically a breaking change, though thinking pragmatically it's only breaking for activity providers who are using an extension that has a hosted schema and they are not following that schema. I suspect that's approximately zero activity providers. Given that a test suite isn't going to use extensions with defined schemas and the way @canweriotnow has arranged the MAY/MUST, this doesn't seem breaking for LRSs either.

If we do go ahead with the change, some specific comments on the wording proposed by @canweriotnow

  1. I don't want to introduce "IFF" in the document. If we were going to use it in a lot of places then it might be useful, but otherwise it adds more complexity than it saves.
  2. There needs to be a bunch more explanation about JSON schema hosting, probably in the metadata section.
  3. We need to tighten up the language around a schema being declared and a schema being availability, which are two distinct concepts. I'd prefer the requirements to be around availability of the schema with the caveat that availability means that either the LRS is able to fetch the schema from the extension IRI, or otherwise access the schema (e.g. from a cached copy, or some other unspecified source).
  4. Do we need to say something about the content type requested?

Most of what I'm suggesting adding would go in the metadata section, so we'd need to add a "see metadata section" somewhere in the extension requirements.

As a side note, on your Cleetus example, you could also filter in just data from known good sources using authority.

Contributor

garemoko commented Nov 30, 2015

For 1.0.3 I worry that this is technically a breaking change, though thinking pragmatically it's only breaking for activity providers who are using an extension that has a hosted schema and they are not following that schema. I suspect that's approximately zero activity providers. Given that a test suite isn't going to use extensions with defined schemas and the way @canweriotnow has arranged the MAY/MUST, this doesn't seem breaking for LRSs either.

If we do go ahead with the change, some specific comments on the wording proposed by @canweriotnow

  1. I don't want to introduce "IFF" in the document. If we were going to use it in a lot of places then it might be useful, but otherwise it adds more complexity than it saves.
  2. There needs to be a bunch more explanation about JSON schema hosting, probably in the metadata section.
  3. We need to tighten up the language around a schema being declared and a schema being availability, which are two distinct concepts. I'd prefer the requirements to be around availability of the schema with the caveat that availability means that either the LRS is able to fetch the schema from the extension IRI, or otherwise access the schema (e.g. from a cached copy, or some other unspecified source).
  4. Do we need to say something about the content type requested?

Most of what I'm suggesting adding would go in the metadata section, so we'd need to add a "see metadata section" somewhere in the extension requirements.

As a side note, on your Cleetus example, you could also filter in just data from known good sources using authority.

@canweriotnow

This comment has been minimized.

Show comment
Hide comment
@canweriotnow

canweriotnow Nov 30, 2015

Contributor

@garemoko Makes sense. I'll start on a PR that incorporates your feedback, might want to get some feedback from you on the branch as it progresses, but I'm sure I can have it ready in a few days... just have to get one pressing client issue out of the way and I can concentrate on doing this up right.

Contributor

canweriotnow commented Nov 30, 2015

@garemoko Makes sense. I'll start on a PR that incorporates your feedback, might want to get some feedback from you on the branch as it progresses, but I'm sure I can have it ready in a few days... just have to get one pressing client issue out of the way and I can concentrate on doing this up right.

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Dec 1, 2015

Contributor

@canweriotnow feel free to open an unfinished PR if you like. Probably the best way to get in-progress feedback.

Contributor

garemoko commented Dec 1, 2015

@canweriotnow feel free to open an unfinished PR if you like. Probably the best way to get in-progress feedback.

@andyjohnson

This comment has been minimized.

Show comment
Hide comment
@andyjohnson

andyjohnson Dec 2, 2015

Contributor

@canweriotnow definitely go ahead with the PR - agree with @garemoko 's comments. I would say "is available" rather than "declared". I think this is okay because the language was always intended to keep LRSs from rejecting Statements with extensions just because they didn't want to deal with them.

Contributor

andyjohnson commented Dec 2, 2015

@canweriotnow definitely go ahead with the PR - agree with @garemoko 's comments. I would say "is available" rather than "declared". I think this is okay because the language was always intended to keep LRSs from rejecting Statements with extensions just because they didn't want to deal with them.

@andyjohnson

This comment has been minimized.

Show comment
Hide comment
@andyjohnson

andyjohnson Dec 2, 2015

Contributor

Per the 12/2/15 call, the worry is LRS interoperability and how an LRS would interpret said schemas. It is a breaking change (although the argument can be made that no LRS would be invalidated as now an LRS would not reject any Statement based on extensions). This would still be a feature, which would make it a 1.1 change.

Contributor

andyjohnson commented Dec 2, 2015

Per the 12/2/15 call, the worry is LRS interoperability and how an LRS would interpret said schemas. It is a breaking change (although the argument can be made that no LRS would be invalidated as now an LRS would not reject any Statement based on extensions). This would still be a feature, which would make it a 1.1 change.

@garemoko

This comment has been minimized.

Show comment
Hide comment
@garemoko

garemoko Mar 2, 2016

Contributor

@andyjohnson can we remove the patch label on this? It doesn't feel like this is going to get addressed for 1.0.3.

Contributor

garemoko commented Mar 2, 2016

@andyjohnson can we remove the patch label on this? It doesn't feel like this is going to get addressed for 1.0.3.

@andyjohnson andyjohnson removed the patch label Mar 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment