Oxygen XML Forum

Hi George,

Quick question. I'm making a big set of RelaxNG schemas that are composed together out of a lot of modular files.

Many of the modular files are intended purely for inclusion in other schemas by means of <externalRef> (i.e. they are in effect RelaxNG "code macros").

Some of these files consist of code fragments that are valid patterns, but are not valid as standalone schemas, usually because they lack a <start> element.

It would be nice to have a way of telling oNVDL that I want these files validated as patterns only, but not as standalones. That would prevent oNVDL from complaining about the lack of a <start> element in these files (and sometimes about other issues that are related to the lack of a <start> element).

Seems like one way to do this would be to have a processing instruction that would tell oNVDL to "cool it" when all I want is pattern validation, not validation as a standalone.

What do you think?

John

P.S. Oh -- and I just thought of a really trivial answer to this, which doesn't involve oNVDL at all, but just involves the oXygen front end: can you have an option under Document Checking to make "missing <start> element" show up as a warning (yellow light) instead of an error (red light)? In fact, could you have a user option under Document Checking to specify that certain user-specified errors get visually flagged in the validation status bars as warnings only? Or perhaps with custom colors?

Hi John,

The problem with documents that are not valid standalone is more generic, that can happen also for XML Schema, XSLT, XQuery and even for XML documents. The solution we provided for supporting working with modules was the introduction of validation scenarios. The validation scenario concept is simple but quite powerful. Basically you can define a set of validate actions that will be performed, for each action you specify the file, the processor and if that should be performed automatically (as you type). For the case you mentioned in this post you can define a validation scenario that validates your main schema (that refers to the schema you edit). Thus you will validate it in the context is is used from.
On the powerful part, the validation scenarios allow you to:

- validate your file against multiple engines
- validate your file in different contexts it is used from
- validate also instances while editing a schema so that you know that your changes keep your old instances valid

combine the above, etc.

Best Regards,
George

George,

That's really cool -- I wasn't aware of that feature. As usual, you're way ahead of me.
Thanks!
John

P.S. Just tried it out and it works like a charm!