Preventing invalid content in Author view

dcramer
Posts: 134

Preventing invalid content in Author view

Thu Oct 05, 2017 6:30 pm

I'm trying to figure out what the default behavior of Oxygen is and if I've broken something with a config or framework change.

If you're in Author view editing a DocBook 5.x document, say in the middle of a para, and press return to bring up the content completion thing, you're presented with a list starting with "Split para", then some recently used elements, then an alphabetically sorted list of elements valid at cursor's location. After all the elements valid at the cursor's location is a list of grayed out element names that are not valid at the current location. If you go ahead and try to insert one of these invalid elements, sometimes it lets you do the invalid thing, for example putting a para inside a para, and sometimes you get a dialog like the one below:

Image

What is controlling this behavior? I assume the intent is to let users make the document temporarily invalid if they know what they're doing, but I'm wondering why sometimes the dialog appears and other times it doesn't. I haven't gotten it to appear in my framework customization, so I don't know if I've broken something, but I also don't know when it should appear and when it shouldn't.

Thanks,
David
sorin_carbunaru
Site Admin
Posts: 111

Re: Preventing invalid content in Author view

Fri Oct 06, 2017 9:37 am

Hello David,

In oXygen we have what we call smart editing strategies. When the user tries to insert an element that is not valid at the current cursor offset, oXygen computes some other solutions to perform the insertion. You can see all these solutions if you deactivate the Automatically apply the best schema-aware insertion operation option from the Schema Aware preferences (https://www.oxygenxml.com/doc/versions/ ... aware.html), which is enabled by default.

The smart editing mechanism shouldn't let you perform invalid insertions like inserting a para inside another para. Sometimes it may insert an element in a valid position, but without all the needed children, which will make the document invalid. However I don't think it should ever let you do things such the para in para insertion. In such cases oXygen should probably show that dialog, so I'd be interested to find out what you did to insert para in para and record a bug. I actually managed this when trying to insert a new paragraph somewhere in the middle of some tracked deletions (https://www.oxygenxml.com/doc/versions/ ... ges_2.html) from another paragraph, but I also want to see how you reproduced this issue.

Sorin Carbunaru
oXygen XML
dcramer
Posts: 134

Re: Preventing invalid content in Author view

Fri Oct 06, 2017 6:56 pm

Ok, now I see what it's doing. In general, it's doing things that make sense. Often it splits elements. For example, if you insert a chapter in the middle of a para in the context /book/chapter/section/para, it closes the current chapter (closing the para, section, and chapter), and inserts a new chapter between that an a newly created <chapter> that encloses all content remaining in the closed chapter. Likewise with paras--I thought it was putting a para in a para, but it was really just splitting the current para and putting one in between. And I think it's doing that even in our framework with its nvdl stuff.

I was also puzzling over what schema(s) Oxygen uses for the purpose of schema awareness, "Automatically apply the best schema-aware", and content completion generally:
  • The schema defined in the Schema tab for the Document type (assuming no schema is defined in the xml file)
  • The schema(s) in validation scenario(s) active for the document, either the default ones or those explicitly selected at any given time.
Based on my experimentation it seems to be the schema(s) for the currently associated validation scenario(s), but perhaps the story is more complicated?

Thanks,
David
sorin_carbunaru
Site Admin
Posts: 111

Re: Preventing invalid content in Author view

Mon Oct 09, 2017 10:39 am

Hi David,

Your observations seem correct, as they match what I also observed on my side -> the schemas apply in the following order:
1. Schema defined in the validation scenario
2. Schema defined in the document
3. Schema defined in the Schema tab of a document type

Sorin C.

Return to “DocBook”

Who is online

Users browsing this forum: No registered users and 0 guests