Index of /1.01/exa/

      Name                                                                             Last modified         Size  Description 
   
up Parent Directory 17-Jan-2015 14:50 - directory BinaryDatalog 05-Mar-2014 04:09 - directory Datalog 17-Jan-2015 14:50 - directory Datalog-xsd 17-Jan-2015 14:50 - directory DatalogPlus 30-Nov-2015 14:18 - directory Dishornlog 17-Jan-2015 14:50 - directory FOLPlus 02-May-2014 21:35 - directory Folog 17-Jan-2015 14:50 - directory Hornlog 05-Mar-2014 04:09 - directory Issues 17-Jan-2015 14:50 - directory MYNG 17-Jan-2015 14:50 - directory NegationDatalog 05-Mar-2014 04:09 - directory RulebaseCompetition2014 17-Jan-2015 14:50 - directory SWSL 05-Mar-2014 04:09 -

Using a Relax NG Schema to Validate Through Validator.nu

Please see the MYNG Demo for a tutorial on using the online tool Validator.nu to validate these examples against Relax NG schemas, XSD schemas or NVDL scripts.

Using an XSD schema to Validate Through Validome

  1. Direct your browser to http://www.validome.org/xml/validate/
  2. Enter the following:
    1. Source: a URL such as http://deliberation.ruleml.org/1.01/exa/DatalogPlus/datalogplus_min_normal.ruleml, or upload a local RuleML file, or paste the Sourcecode into the text area.
      1. Note: the RuleML file must contain an xsi:schemaLocation attribute referencing a RuleML XSD schema such as http://deliberation.ruleml.org/1.01/xsd/datalogplus_min_normal.xsd
    2. Check the View Sourcecode checkbox.
    3. Click Validate.

Validation Instructions in oXygen

In the instances in this examples directory, xml-model processing instructions (PIs) are used to indicate the minimal RNC and XSD schemas that the instances should validate against. An xml-model processing application, such as oXygen (http://oxygenxml.com) will use these PIs to determine the schemas to be used for validation. Unfortunately, the RuleML Version 1.0 XSD schemas are not validated by oXygen's default XSD validator, Xerces, due to circular definitions. These XSD schemas are validated by Saxon EE (with warning messages) and XSV (with no warning messages). Ideally, a user would configure oXygen to use a non-default XSD validation engine, enabling validation of an instance against both RNC and XSD schemas. Unfortunately, in oXygen versions up to at least 13.1, this configuration setting causes oXygen to attempt to apply the Saxon engine to the RNC schema, which produces an error message. This bug has been reported and is scheduled to be fixed in oXygen 13.2. The xml-model processing instruction for the XSD schema has been commented out, so that it can be easily activated once this oXygen issue is fixed. Also a RuleML start tag that includes the xsi:schemaLocation attribute is available in a comment in each file, for use with validators that do not understand xml-model processsing instructions.

As a temporary workaround to this oXygen issue, one may apply a custom validation configuration to each subdirectory, except for the MYNG subdirectory, where each file requires a custom validation configuration. Each configuration contains two validation scenarios:

  1. the default validation scenario, which activates the xml-model PI with the RNC schema;
  2. a scenario specifying the XSD schema appropriate to that instance or subdirectory, and a validation engine (either Saxon EE or XSV)
Once these configurations have been set, batch validation may be performed on the entire exa directory.

Hint: the oXygen "Information" view provides helpful information about the batch validation process, beyond what appears in the "Results" pane.

Proudly Served by LiteSpeed Web Server at deliberation.ruleml.org Port 80