Javadoc

The javadoc specifies the legal properties that can be set with RDFReader.setProperty. This method can be used to modify the behviour of the HTML parser and the RDF/XML parser It also documents GRDDLSecurityException that is thrown whenever a transform attempts an operation that has been blocked for security reasons.

The GRDDL Reader Javadoc (Public APIs)

HTTP 503 Errors and copies of W3C DTDs

Read this section if you get 503 errors, particularly from W3C servers, particularly for DTDs.

There is an unfortunate interaction between the GRDDL spec. that assumes that the Web functions at the level of DTDs and namespace documents, and the sad realities of life if you run a central server at the W3C.

The GRDDL code is written as if all DTDs and namespace documents can be retrieved and inspected (or simply don't exist). Since, for the important DTDs at W3C this is not true, there is a private copy of several DTDs included in the GRDDL jar. These are also visible in the distributed zip (directory w3c-dtds).

It is quite possible that the DTDs included in the GRDDL jar will become out of date, or not include a DTD that you need. In this case, to replace the default, you need to copy the w3c-dtds to your system, modify any DTDs that are out of date, add any further DTDs you need, and modify the catalog.xml file. Having done this, you then use two system properties on the command line, to tell the GRDDL reader to use your version, rather than its own.

xml.catalog.files

A semi-colon separated list of absolute URIs (or relative file names), each being an XML Catalog file.

jena.grddl.allowDirs

A semi-colon separated list of directories. Read access to these directories will be permitted from the GRDDL sandbox. This is needed because typically the catalog file(s) will point to local copies of the DTDs etc. Access to local files from within the GRDDL transform is usually prohibited.

A different fix, is to use the first of these properties with a non-existent catalog file. This suppresses the default behavior. Correct functioning of the Web (at least in this respect) can be ensured by the appropriate use of a proxy, see W3C blog entry and discussion.

Suppressing the License Dialog

The dialog concerning acceptance of the license may not always be appropriate. In certain uses of the Jena GRDDL Reader, it may not be possible for the license dialog to be displayed, and the system may hang, or exit, unexpectedly: e.g. within tomcat; in a headless configuration; on a command-line only system; or in a system which does not support Java Swing .

If the user has agreed to the license terms, aware of the risks associated with the software, then the license dialog may be suppressed.

There are two methods for doing so.

Copying or Reusing the Configuration File

The first method, is for the user to first agree to the license, using a configuration which does support Swing.

If the same home directory is used for both the initial use and the problematic use, then the software should be able to read the configuration file and see that the license has been accepted, and the dialog will not be displayed.

If the user is using a different home directory, then the configuration file will need to be copied from one home directory to the other.

If the user is using a different user name on the second system, then the configuration file will also need to be edited.

The configuration file location is:

Using a System Property

It is also possible to suppress the license check by telling the system that the user has agreed to the license by means of a system property.

The system property "jena.grddl.license" may be set to the value (all one line) "The end-user understands the risks associated with running GRDDL software. The end-user agrees to the BSD license for the Jena GRDDL Reader." This is intended for the cases in which these sentences are in fact true!

Running Inside Tomcat

This has not been tested, and will probably not work. However, if you want to try, please send e-mail to jena-dev, and I'll try to help if I have the time. Note that this is, for this release at least, likely to be less secure than might be expected, due to unfortunate interactions between the Tomcat security code and the Jena GRDDL Reader security code.