Response to WL1

From RIF
Revision as of 01:50, 15 October 2008 by Harold Boley (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Wolfgang Laun wrote:

> Assuming that much of the software for processing XML in the RIF
> sublanguages will be written in Java, it is highly probable that 
> much of this will be done using JAXB, the "Java Architecture for 
> XML Binding". Sun's Java 1.6 comes bundled with an XML Schema 
> compiler. I have investigated the XML schema for the RIF Condition
> Language.

Thanks much for doing this analysis.

> The schema as given in the "RIF Basic Working Draft 30 July 2008" compiles
> into 33 Java classes. Using a different approach, essentially the same
> XML definition can be expressed in an XML schema which compiles into
> only about 20 Java classes.

It would be instructive if you could share this with us at some point.

> The current XML schema does not try to exploit inheritance by XML type
> extension. (This would be possible for IRIMetaType as a base type.)

We do use some other kind of inheritance, though.

> Using the xsd:choice construct results in class definitions with several
> fields where only one is used (example: Formula). Such objects are
> awkward and, potentially, error prone.

Isn't that an issue with JAXB, and not really something RIF should solve? After all, xs:choice is a fundamental part of XML Schema.

> It would be preferable to use explicit complexType and simpleType
> definitions (rather than inlined types) as this makes it possible to reuse
> the same type for differently tagged elements.

Our intent was to keep most things explicit. We seem to have ended up with some inlined types. (Perhaps just within groups?)

> If it is a concern of  the working group to formulate an XML schema
> which simplifies its usage for Java programmers then a rework of the
> schema definition should be considered. I'd be glad to contribute my
> work towards an alternate version.

An unofficial JAXB-friendly version of the XSDs is always possible, of course.