Command: xsdwrite

Syntax

xsdwrite <channel>,<ident>

Description

Creates an XSD file from a Fire class structure. Output is written to a system output channel.

Parameters

• <channel>
  A channel identifier.

• <ident>
  An identifier whose class structure is to be converted, or a class structure itself.

Switches

• -enc=<string>
  Include an encoding attribute in the xml header. If this switch is omitted, the encoding attribute is excluded. Typical encoding values are "UTF-8", "windows-1252" etc. This switch is ignored if header output is suppressed.

• -h
  Write the xml header. This is the default behavior. By suppressing this (-no_h) customized header can be written to the channel instead.
  The default header text is <?xml version="1.0" ?>

• -ns=<url>
  The namespace url to be used as the target namespace in the xsd output. If this omitted, the namespace url associated with the class to be written is used. This is typically a web page describing the schema. Both a namespace url and a namespace prefix (-pre) are usually supplied.

• -pre=<string>
  A namespace prefix to be used within the xsd output for simple and complex type definitions. If this omitted, the namespace prefix associated with the class to be written is used. Typically both a prefix and a namspace url are supplied.

• -tag=<string>
  The name for the root element in the xsd output. If <ident> is an object, then the name of the object is used. If <ident> is a class then this switch must be supplied.

Notes

The output of this command is simplistic (by xml standards) and its use is primarily for creating a rough cut of an xsd schema from a Fire class.

This command is not the reverse of the xsdread command since there are many xml concepts which have no parallel within the system. It is intended merely to be a utility command for those unfamiliar with the intricacies of xsd schemas.

Default and fixed values are not included in the output although other xml output characteristics attached to the Fire class structure members will be used where possible. Most Fire member types are mapped to xml string types.

Typically, post creation, the xsd schema file would be manually edited to set any array limits, value constraints and input/output rules for which there are no Fire equivalents.

Example

Consider a (totally fictional) Fire structure, containing a sub-structure element:

atable test
structure ~test.subthing_t {
   time t,-tdo;         # Date only i/o
   window w
}
structure ~test.thing_t {
   xml attribute {
      numeric xvalue
      string name
      string option[];  # Optional attribute
   }
   string svalue
   string tokens[],-lis;# List of values
   numeric nvalue,-int; # Integer value
   blob image,-hex;     # Hexadecimal binary i/o
   ~test.subthing_t subs[]
}

The commands to create an xsd schema file from this structure might be as follows:

open ch,-of=thing.xsd
xsdwrite ch,~test.thing_t,-tag='thing',-pre='acme',-ns="http://www.acme.net/"
ch.close

The resulting xsd file would be like this:

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:acme="http://www.acme.net/"
      targetNamespace="http://www.acme.net/"
      elementFormDefault="unqualified" attributeFormDefault="unqualified">
   <xsd:element name="thing" type="acme:thing_t" />
   <xsd:simpleType name="stringList">
      <xsd:list itemType="xsd:string" />
   </xsd:simpleType>
   <xsd:complexType name="subthing_t">
      <xsd:sequence>
         <xsd:element name="t" type="xsd:date" />
         <xsd:element name="w" type="xsd:token" />
      </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="thing_t">
      <xsd:sequence>
         <xsd:element name="svalue" type="xsd:string" />
         <xsd:element name="tokens" type="acme:stringList" minOccurs="0" />
         <xsd:element name="nvalue" type="xsd:int" />
         <xsd:element name="image" type="xsd:hexBinary" />
         <xsd:element name="subs" type="acme:subthing_t" minOccurs="0" maxOccurs="unbounded" />
      </xsd:sequence>
      <xsd:attribute name="xvalue" type="xsd:decimal" use="required" />
      <xsd:attribute name="name" type="xsd:string" use="required" />
      <xsd:attribute name="option" type="xsd:string" />
   </xsd:complexType>
</xsd:schema>

You will see how the class definitions 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.

When an xsdread command is used to create Fire classes (the reverse of this command), such constructs and switches are added automatically to Fire class creation statements.

As mentioned in Notes above, Fire classes created by an xsdread command will not necessarily produce a fully functional xml schema when processed by an xsdwrite command. However the output from an xsdwrite command should always re-create the correct Fire structures when subseqeuently read by an xsdread command.

See Also