Export (New XML Style) before run

The Export2 button brings up the (newer) XML Schema Export Dialog box, used for generating XML Schema sets from the database. The ASN source code exporting process is covered in the previous Dialog; see Export Formatting (old).
This section presumes the reader is generally familiar with the process of XML schema creation and the design issues involved.
Exporting a useful XML schema is slightly harder than exporting an ASN file. You have to plan what you want to end up with, define how it will be named, and then resolve the linkages to other schema from other standards that you depend on.
In ASN source file creation, these items are all done for you and the tool produces a single file with multiple modules inside it for each FADD used. Things are more complex in XML. For one, in the XML world of ITS each FADD namespace has it own file (as well as its own supporting local codes file) and you will either use this complete file (typically obtained from the SDO that issued it) or will construct a partial sub-set of it with only the entries you require from the records in the ExternalDEs table.
 |
Background: Schema files in the ITS world have their revision value as part of the file name. Typically this is also carried over in the import string used in the header sections of the schema to point to other supporting schema files. The name pattern is several keywords separated by dashes, as follows:
[FADD] - [Draft] - [MajRev] - [MinRev] - [IncRev].xsd |
The FADD is of course defined by the standard. The term Draft is used for most working standards but the term Adopted is used for the final issued standard. This term is typically changed by hand by the data steward.
One additional pattern is the name of the file which contains the local codes (extensions) to each FADD; these are called: [FADD] - [Local] - [Draft] - [MajRev] - [MinRev] - [IncRev].xsd
The Mini-Edit tool automates much, but not all, of this process. It will produce a working schema for your data files from the standard tables, but can not usually produce a complete working schema for other imported standards in the External DEs tables due to not having ALL the relevant data concepts and not knowing what other revision releases in the other standards it needs to link to when it builds the foreign schema file. This is reflected in revision strings of 00-00-00 which can be interpreted to mean an unknown revision. Users can manually change these when a revision is known, or can make the 00-00-00 work as well.
Another ITS convention to mention is that related schema files are presumed to be locally found alongside each other. Hence local relative addressing is used for files, not absolute addressing.
This method of naming is used in the three critical places in the files. The XML schema standard allows different names for each location, but this has not proved to be useful to ITS and as a convention we avoid it.
Consider an illustrative example of the TMDD data dictionary at revision 02-01-00 rendered into an XML schema.
- This schema file would be called: TMDD-Draft-02-01-00.xsd
- Inside, its target namespace would be: http://www.tmdd-Draft-02-01-00
(the word Partial would replace the word Draft if this was rendered from the ExternalDEs Table in another database such as ATIS)
- When other schema files point to this data dictionary rendered as a schema they would use the namespace TMDD mapped to the string: http://www.tmdd-Draft-02-01-00 which would be imported from the locally defined file named: TMDD-Draft-02-01-00.xsd
(although you will also find uses of the file name: tmdd.xsd when no revision baseline of the TMDD data is known).
 |
Keep in mind in these examples that http://www.... is a common industry convention used to provide a unique string; it is not intended to be a linkable URL. | Resolving your external data so that it comes from the right schema release (Draft, Adopted or Partial) as well as what the revision value is between each of the related files is typically a manual effort after the schemas are created. This is expected to be made much easier when a user can simply drop an entire adopted schema into the mix. Note that this system also allows for the annoying reality that each standard may in fact point to different versions of other standards.
This tool, and this Dialog, allows you to create your own FADD and render that into a well formed schema.
User URL base
The URL base is used to insert the starting URL location for web service endpoints. It is used in WSDL and SOAP mappings.
Aside: Unlike an XML schema, a WSDL file is customized for each user because it contains the URL where the service endpoint can be found.
|
User local folder
The folder (local to the Mini-Edit application path) where the schema set will be built. The schema will be placed inside a folder under this folder which reflects the name and revision of the primary schema which is being built. This location is also used to place the web page documents, if any are produced.
|
Local or Custom Table Select
This is section 1 of the four output sections. It allows selecting whatever single table you wish as the output, although it defaults to the local table. If the box is checked, the selected table will be output. Note that the file name, derived from the FADD as well as the table name and the current database revision, is shown.
|
Key Table Select
This is section 2 of the four output sections, used to output the primary table contents of the standard. You may check or un-check each of the three boxes to control the output of Data Elements, Data Frames, and Messages tables respectively. Normally all three are checked. All of these records will be placed into the one file shown. Note that the file name, derived from the FADD as well as the table name and the current database revision, is shown.
|
Dialogs Table Select
This is section 3 of the four output sections, used to output the WSDL for any defined Dialog s in the standard. You may check or un-check the box to control the output. A WSDL file is basically created the same way as an XSD file; the XML in each relevant record is gathered and placed in the WSDL file. Note that the file name, derived from the FADD as well as WSDL and the current database revision, is shown.
|
External Entries Table Select
This is section 4 of the four output sections, used to output partial XML schema files for the External data concepts in the standard. You may check or un-check the box to control the output. Normally it is un-checked and ideally you would obtain the adopted edition of the schema from the issuing SDO rather then render them out here. When rendering from the External DEs table, each record is mapped to its module/FADD home and a separate file is created for each FADD. Note that the file naming used, derived from the mapped FADD and using the known database revision (00-00-00), is shown.
|
Status Display
This area provides a working status as the export occurs. A progress bar also appears during the rendering. See the post-run screen shot for an example.
|
Revision Release
The revision values for the database are displayed here and you may set and advance them as you see fit. This information can also be found in the Misc Text table if you wish to edit it there. Typically the last number is an ever-increasing revision value while the other two follow the numbering conventions of each SDO.
|
Namespace Select
The FADD namespace is specified here. This information can also be found in the Misc Text table if you wish to edit it there. Each SDO and each standard has been assigned an FADD value at this time (kept in the Module-Names table of the MEdit_Settings.mdb file). It is expected that local deployments may need to establish a FADD value of their own as well.
|
Export Counters
The number of records exported during the run is shown here. Also, an icon appears if any records were created which the user can click on to see the created files. This will launch the application the user has registered for viewing *.XSD files, (refer to how to register file types here).
|
Run button
The run button is the do it command for this Dialog.
|
Cancel button
This closes the export XML Dialog, returning you to the main window.
|
![11424034]()
|