This issue is about leveraging Create.js + VIE cleanly and properly instead of hackily like we have to do today due to Drupal limitations.

  • In Edit, we weren't able to fully leverage Create.js+VIE's built-in discovery system (powered by RDFa) because Drupal's RDFa support is not good enough (not my words, but an objective observation by the Create.js/VIE developer). This implies properly leveraging VIE's type system, which also implies a cleaner way of determining which Create.js PropertyEditor widget should be used for a field (for that, also see #1874936-2: Pluggable in-place editors (allow modules to define new Create.js PropertyEditor widgets) and #1874936-3: Pluggable in-place editors (allow modules to define new Create.js PropertyEditor widgets)).
  • Because at the time of development there was no REST API yet to retrieve and update content from Drupal, we had to implement a Backbone.sync implementation on top of forms as a transport layer. This clearly is ugly, fugly, doomed to have or cause problems, etc. We should be leveraging Drupal 8's new JSON-LD, but then that needs to have validation support first (we of course don't want to save invalid data).

This is blocked on:

  1. #1778226: [META] Fix RDF module
  2. #1784216: [META] JSON-LD support
  3. #1696648: [META] Untie content entity validation from form validation

Comments

I mentioned this on Twitter, but I think this is a D9 issue. There's a lot to unpack when it comes to relying on RDFa and JSON-LD here.

As I mention in the fix rdf issue that you included, the RDFa in Drupal 7 is unreliable. It doesn't work for compound fields such as AddressField and Fivestar. It gives bogus data for some fields which add links to their data, such as Field Collection and Relation. It doesn't work if you use Views or Panels, or if you move fields outside of the entity div using something like hook_page_alter.

So we need to fix this. It is difficult to find people who can fix these issues because you fist need to understand the RDF triple model, which devs don't seem to. You then need to understand the RDFa processing model enough to make sure that you aren't creating brittle RDFa, like using hanging-rel chaining in the wrong place... which very few people in the world do (that's not a jab, I'm pretty sure Manu would agree with that statement).

In addition, we need to implement the JSON-LD. As I mentioned in Two JSON-LDs for Drupal, the data structure we will use for content deployment is different than the one CreateJS needs. CreateJS needs to align with the data in RDFa, which needs to align with external vocabularies like Schema.org.

We have high aspirations for these technologies, but we don't have enough devs digging into the details to make it work in a short timeframe.

Indeed we first need to have better RDFa support in core, which is tracked in #1778226: [META] Fix RDF module. For the case of Edit, we should use the site schema which was introduced in #1852812: Use cache to get entity type/bundle metadata from JSON-LD @type URI, and which gives each field its own URI. We should also use the Drupal-specific model in RDFa/JSON-LD used in the context of content deployment, see example at #1831286: Provide machine-readable description of entity/field/property. That way JSON-LD entities mirrored in VIE from the RDFa in the page can be sent pretty much as is to Drupal to be saved by the Entity API. I'm picturing an ideal situation here, but I hope we can get there :)

Hmmm... so the site schema that was introduced is actually TWO site schemas. Are you suggesting that we include both in the page? FYI, that would actually be impossible to do unless we duplicate content in invisible meta tags since they model things in such a different way.

Per #1924854-6: [META] Hypertext Application Language (HAL) support, we'll likely need to rethink this based on HAL, but probably makes sense to keep this postponed until that meta issue is further along.

Status:Postponed» Closed (fixed)

#1979784: Factor Create.js and VIE.js out of the Edit module removed Create.js and VIE.js, so this was implicitly fixed there.