Next Changes to PERF Schema

[mvahowe]

Please post proposals for specific changes to the PERF schema below. (Let's do wider discussions elsewhere.) I'll maintain the list in this description on the basis of comments below.

Names

• change block in blockOrGraft (ie children of a sequence) to paragraph

Roll back existing preview features

• Remove the nBlocks and firstBlockScope attributes from grafts
• Make previewText attribute on grafts optional (in case downstream processors need it)
• remove selected flag

Better graft support

• Add a 'new graft' variant of grafts, with no target and new: true to request a graft to a new, empty sequence
• Consider support for permalink 'grafts'

Supporting remaining USFM features

• add markup for Proskomma scopes within a paragraph, eg \add inside \wj, with optional attributes
• add markup for marks (empty milestones) and backport to chapter/verse
• add markup for start and end milestones with optional attributes

Context-specific augmented content

• allow an optional augmented array of typed objects, attached to any item, as a mechanism for upstream PERF processors to push content-specific additional content to the editor, eg chapter/verse consistency, spell checks, relevant permalinks... The objects should have a consistent, defined structure, with an enum of known functionality plus provision for x-* extensions.
• add a augmented scope-like option (ie similar to \wj) for items so that augmented content may be attached to 'bare' text and to arbitrary item ranges within a paragraph

Miscellaneous

• Optional timestamp for document

[mvahowe]

@klappy @superdav42 "Context-specific augmented content" is my proposal for supporting 'warnings' (and much more). It avoids wrapping every single piece of text in a span 'just in case', but we can do that when there's specific content to attach and, for the consuming processor, that will look exactly like any other 'scope-like' markup (in the Proskomma sense of 'scope'). Does this look like it could support what we want, or, at the least, the next few iterations of experiments?

[mvahowe]

(You can see Dave's example of a possible test with 'push' warnings at

epitelete/src/index.js

Line 146 in fc9a78b

async checkPerfSequence(perfSequence) {

.)

[klappy]

I like the idea of the embedded warning for the editors sake. Especially the entire round trip we make, this seems logical.

In my case having it projected onto the dom elements as data-warnings and we can put a yellow/red squiggly under the entire element.

If need be we can inject inline spans for more targeted warnings.

With that said, I could also imagine a separate payload for rendering the validation errors/warning any way you want.

So maybe and/or make sense.

[superdav42]

I'm not sure I understand how it will look. An example would help but it sounds like it will solve the problem.

[mvahowe]

@abelpz All suggestions on how to make the permalink part of this proposal work would be very welcome!