compaction: t0112, t0113 in LD 1.0 processing mode

[daenney]

I'm running into an issue with t0112 and t0113 in compaction. No specVersion or processingMode is specified for those tests, so I'm assuming they should pass in ld-1.0 and ld-1.1.

However, I can't get them to pass on 1.0.

For t0112, the context is:

{
  "@context": {
    "ex": "http://example.org/ns/",
    "prop": {
      "@id": "ex:prop",
      "@container": "@index",
      "@index": "ex:name"
    }
  }
}

For t0113, the context is:

{
  "@context": {
    "ex": "http://example.org/ns/",
    "prop": {
      "@id": "ex:prop",
      "@container": "@index",
      "@index": "http://example.org/ns/name"
    }
  }
}

When running in LD 1.0 mode, I get an "Invalid Term Definition", based on step 20.1 in Create Term:

If value contains the entry @index:

• If processing mode is json-ld-1.0 or container mapping does not include @index, an invalid term definition has been detected and processing is aborted.
• Initialize index to the value associated with the @index entry. If the result of IRI expanding that value is not an IRI, an invalid term definition has been detected and processing is aborted.
• Set the index mapping of definition to index

The way I'm reading that is that if a property definition has an @index entry, and we're in LD 1.0 mode we need to bail out. The definition of prop includes @index, so it can't pass?

Looking at the expansion tests, I don't think there's one where @index is set on a term in an @context that runs for LD 1.0.

[gkellogg]

• If processing mode is json-ld-1.0 or container mapping does not include @index, an invalid term definition has been detected and processing is aborted.

You're correct that these should both be set to "specVersion": "json-ld-1.1" based on that clause.

This was probably not caught, as we don't expect developers to work towards a distinct "1.0" vs. "1.1" mode, but rather wanted to give a way for developer who were using the 1.0 test suite to filter out 1.1-specific tests (and for 1.1 developers to ignore specific 1.0 tests).

Fixed in #655.

[daenney]

Brilliant, thanks!