Glossary Item Box

MEdit Send comments on this topic.

Export (New XML Style) before run

Export (New XML Style) before run

 

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.

1User URL base

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.

2User local folder

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.

3Local or Custom Table Select

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.

4Key Table Select

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.

5Dialogs Table Select

Dialogues 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.

6External Entries Table Select

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.

7Status Display

8Revision Release

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.

9Namespace Select

10Export Counters

11Run button

Run button The run button is the do it command for this Dialog.

12Cancel button

11424034

   <-LAST     TOP      NEXT->  

 

 


© SubCarrier Systems Corp. All Rights Reserved.