Menu

#89 XSD/Code/XML mis-matches.

open
nobody
None
5
2012-10-31
2010-12-20
No

Trying to validate all of the current CVS aircraft using xmllint and the XML validator available in Eclipse (3.6+), I've come up with the following items that either need to be fixed in the aircraft (or systems or scripts) or the appropriate schemas need to be updated. Some of these work in the code and just haven't made it over to the schema(s).

======

The following list some of the elements that don't validate with the current XSD files,
but can't be definitively marked as errors and fixed.

1) <retractable></retractable>

XSD: Integer
Code: el->FindElementValueAsNumber("retractable")
XML: "RETRACT" (F4N but not F4N-jsbsim.xml), "FIXED" (dr1, Short_S23). All others are 0/1.

Should "RETRACT" and "FIXED" be accepted? Or should the three aircraft just be fixed?

2) <documentation></documentation>

This is not a valid element in any of the XSD documents (JSBSim.xsd, JSBSimScript.xsd,
JSBSimSystem.xsd). It is used extensively in the following models, but nowhere else:

Boeing314
Concorde
Short_S23 (including Systems/[engines, fuel-system, hydrodynamics, take-off-ap])
Submarine_Scout
ZLT-NT (Systems/[air-and-gast-control, engine-control)

Of course the last three aircraft (and the first two as well?) are by Anders Gidenstam.
There are incredible details about how the model was developed in the <documentation> elements.
The information should be lost.</documentation>

As the <documentation> tags are currently used in the above aircraft, it would be a big
job to add them to schemas since they are freely sprinkled throughout the file. They'd
have to be added to many elements.</documentation>

It might be possible to convert a large number of them to <description> elements, if those were
added as discussed elsewhere.</description>

The other possibility would be to convert them all to XML comments such as

This would only take a couple of minutes, and could be automated.

I don't know if Anders or others have a tool or tools that actually use those tags, i.e. extract
the information found in the <documentation> elements out for some purpose.</documentation>

3) <tank> <priority></priority></tank>

4) <license></license>

By the schema, license needs to be written with attributes like this:

     <license
       licenseName="GPL (General Public License)"
       licenseURL="http://www.gnu.org/licenses/gpl.html"/>

In a number of aircraft (~10), <license> is written with child elements like this:</license>

     <license>
       <licenseName>GPL (General Public License)</licenseName>
       <licenseURL>http://www.gnu.org/licenses/gpl.html</licenseURL>
     </license>

Either these need to be converted to the former, or the schema needs to be expanded to accept
this as well.

5) <filecreationdate></filecreationdate>

I've mentioned this at times before. The format of the date inside the element must be in ISO 8601
format: YYYY-MM-DD

xmllint doesn't allow any spaces surrounding the date when validating, although it seems
that it should. To make it happy, it is best to leave them out. Other validators don't mind. Thus

<filecreationdate>2010-12-06</filecreationdate>

and not this

<filecreationdate> 2010-12-06 </filecreationdate>

or anything else like "now", "06-Dec-2010", etc.

6) <property> inside of <system></system></property>

<property> elements inside of <system> elements have an optional "value" attribute
that is only defined in the JSBSimSystem.xsd, not the JSBSim.xsd which only uses an ordinary property
element that doesn't have the optional "value" attribute.</system></property>

Only the ah1s seems to use it so far, to declare and initialize properties, but that may change
in the future.

7) <clipto></clipto>

<min> and <max> are limited to xs:double in JSBSim.xsd, while the code allows signed properties.</max></min>

8) <width> in <deadband></deadband></width>

Is limited to xs:double in JSBSim.xsd, while the code allows signed properties.

9) JSBSim.xsd has various xs:float and xs:double elements. It isn't immediately clear
if these are different or not.

10) <description></description>

This element has been used in some aircraft as a child to many elements. It would be
beneficial to add this to all of these elements and any others where it might also be useful.

children of:
aerosurface_scale: c172x
actuator: c172x
fcs_function: f22
aerodynamics
ground_reactions
tank: B17

aircraft - element:

11) <aero_ref_pt_shift_x></aero_ref_pt_shift_x>

12) <switch> with multiple <output></output></switch>

13) <actuator> with <rate_limit> (J246)</rate_limit></actuator>

14) <pointmass> and </pointmass>

<form>

15) <function> </function>

<v></v>

16) <contact> <steerability> (p51d)??</steerability></contact>

17) <contact> <orientation></orientation></contact>

18) <aerodynamics file=" "> (Short_S23)</aerodynamics>

19) <pointmass> <weight> and <location> order (Submarine_Scout, ZLT-NT)</location></weight></pointmass>

20) <damping_coeff type="SQUARE"> (X15)</damping_coeff>

21) <feed> required for electric motors</feed>

22) Define <buoyant_forces></buoyant_forces>

23) check_cases/ground_test: abbreviated <metrics>, empty <aerodynamics></aerodynamics></metrics>


Tools:

1: xmllint
a) Explicitly say which schema is used to validate each file via Makefile.am. Ignores the
internal schema declaration.

2: XML validator within Eclipse:

a) Must set it to use local .xsd file, or it goes out to the network for the actual file.
Good and bad.
b) Xerces based
c) Automatically tries to validate all XML files. If no schema is included in the file,
it only gives a single warning "No grammar contraints (DTD or XML schmea) detected
for the document."

</form>

Discussion


Log in to post a comment.