Command: xsdread
Command: xsdreadxsdread <xsdfile>
Reads an XSD file and converts the contents into a series of Fire class structures reflecting the XML schema within the file.
<xsdfile>
The XSD file to read. This can be a local file or any URL. Typically this
will be a .xsd file, or an .xml data file containing a reference to a .xsd
schema file, in which case the referred-to schema file will be read.
-es=<ident>
Record parsing errors in a string array identifier.
If the identifier does not exist, a new string array is created using current
scope rules. Each error is recorded in a separate array element.
If this switch is included, errors are directed to the error log.
-of=<macrofile>
The name of a Fire macro file to be created. All commands produced by analysis
of the xml schema will be written to this file. Such commands will comprise
class structure definition commands. If this switch is omitted, the command
output is displayed in the monitor window. When such a macro is subsequently
executed, classes created from root-level elements in the xml schema retain
the tag name and xsd url information. This information can be used by the
xmlread command and
the xmlclass function.
-raw
If the target file is an xml file without a reference to a .xsd schema,
make an attempt to to create Fire structures from the xml contents with
the necesary limitations. Differentiation will be made between elements
and attributes, structure names will be derived from the element names and
crude decisions will be made regarding which elements are arrays and which
attributes are optional. All elements are assumed to be of type string.
Without this switch, the default behavior is to
regard an xml file without a .xsd reference as an error.
XML parsing is performed using the Xerces SAX parser, but full xml validation is not done on the schema contents, although the elements and attributes are checked for legality.
No atable prefixes are applied to the class creation output commands. It is assumed that the caller will make appropriate arrangements when the macro is subsequently executed.
Consider a .xsd schema file (name services.xsd).
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xmarc="http://www.xmarc.net/"
targetNamespace="http://www.xmarc.net/"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">
<xsd:element name="services" type="xmarc:ServicesType"/>
<xsd:simpleType name="YesNoType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="yes" />
<xsd:enumeration value="no" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SchemeType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="http" />
<xsd:enumeration value="https" />
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ServicesType">
<xsd:choice>
<xsd:element name="register-service" type="xmarc:RegisterServiceType"
maxOccurs="unbounded"/>
<xsd:element name="unregister-service" type="xmarc:UnregisterServicesType"
maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RegisterServiceType">
<xsd:sequence>
<xsd:element name="web-server" maxOccurs="unbounded"
type="xmarc:WebServerType"/>
<xsd:element name="agent" maxOccurs="unbounded" type="xmarc:AgentType"/>
<xsd:element name="command" type="xmarc:CommandType"/>
<xsd:element name="launch-timeout" minOccurs="0" type="xsd:integer"/>
<xsd:element name="queue-timeout" minOccurs="0" type="xsd:integer"/>
<xsd:element name="idle-timeout" minOccurs="0" type="xsd:integer"/>
<xsd:element name="private" minOccurs="0" type="xmarc:YesNoType"/>
<xsd:element name="secret-key" minOccurs="0" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="name" use="required"/>
</xsd:complexType>
<xsd:complexType name="UnregisterServicesType">
<xsd:sequence>
<xsd:element name="web-server" type="xmarc:WebServerType"
maxOccurs="unbounded"/>
<xsd:element name="service-instance" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="host" use="required"/>
<xsd:attribute name="port" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="secret-key" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="name" use="required"/>
</xsd:complexType>
<xsd:complexType name="WebServerType">
<xsd:sequence>
<xsd:element name="scheme" minOccurs="0" type="xmarc:SchemeType"/>
<xsd:element name="context" minOccurs="0" type="xsd:string"/>
<xsd:element name="password" minOccurs="0" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="host" use="required"/>
<xsd:attribute name="port"/>
</xsd:complexType>
<xsd:complexType name="CommandType">
<xsd:sequence>
<xsd:element name="param" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="program-name" use="required"/>
</xsd:complexType>
<xsd:complexType name="AgentType">
<xsd:sequence>
<xsd:element name="service-port" minOccurs="0" type="xsd:integer"/>
<xsd:element name="service-instances" minOccurs="0"
type="xsd:unsignedShort"/>
<xsd:element name="command" type="xmarc:CommandType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="host" use="required"/>
<xsd:attribute name="port" use="required"/>
</xsd:complexType>
</xsd:schema>
This might be read by the following command:
xsdread services.cmd,-of=create_services_classes.cmd
The resulting macro file (create_services_classes.cmd) created by the xsdread command would be as follows:
structure webservertype_t {
xml attribute {
string host
string port[]
}
string scheme[],-st
string context[]
string password[]
}
structure commandtype_t {
xml attribute {
string program_name,-tag="program-name"
}
string param[]
}
structure agenttype_t {
xml attribute {
string host
string port
}
numeric service_port[],-tag="service-port",-int
numeric service_instances[],-tag="service-instances",-int
commandtype_t command[]
}
structure registerservicetype_t {
xml attribute {
string name
}
webservertype_t web_server[],-tag="web-server"
agenttype_t agent[]
commandtype_t command
numeric launch_timeout[],-tag="launch-timeout",-int
numeric queue_timeout[],-tag="queue-timeout",-int
numeric idle_timeout[],-tag="idle-timeout",-int
string private[],-st
string secret_key[],-tag="secret-key"
}
structure service_instance_t {
xml attribute {
string host
string port
}
}
structure unregisterservicestype_t {
xml attribute {
string name
}
webservertype_t web_server[],-tag="web-server"
service_instance_t service_instance[],-tag="service-instance"
string secret_key[],-tag="secret-key"
}
structure servicestype_t,-tag="services",-pre="xmarc",-ns="http://www.xmarc.net/",-xsd="services.xsd" {
xml choice {
registerservicetype_t register_service[],-tag="register-service"
unregisterservicestype_t unregister_service[],-tag="unregister-service"
}
}
You will see how the class creation commands have some xml constructs (new to Fire 7.1) and element switches. These are added for xml input/output purposes only and have no relevance during non-xml language operations. When objects of a particular class are read by the xmlread command, or written by the xmlwrite command, this auxiliary information provides xml formatting and layout information.
Class structures are always members of application atables, so when the above macro is executed to create them, the atable scope would be set accordingly, e.g. to add these structures to an atablel myatab, the following command sequence would be used:
atable myatab scope=myatab exec create_services_classes,-sc
|
Commands: |
|
|
Functions: |
|
|
Structures: |