XML Tag Definitions

Tutorial User Guide > Drive Pages > XML Tag Definitions

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''">

XML Tag Definitions

The Acronym XML stands for Extensible Markup Language. The World Wide Web Consortium (W3C) announced on February 10, 1998 the XML 1.0 specification as the first Recommendation for the Extensible Markup Language, a system for defining, validating, and sharing document formats on the Web.

The W3C press release can be viewed at:

http://www.w3.org/Press/1998/XML10-REC.html

XML was created and developed by the W3C XML Working Group, which includes key industry players such as Adobe, ArborText, DataChannel, Inso, Hewlett-Packard, Isogen, Microsoft, NCSA, Netscape, SoftQuad, Sun Microsystems, Texcel, Vignette, and Fuji Xerox; as well as experts in structured documents and electronic publishing.

The motivation for developing XML was to overcome limitations experienced with the defined HTML markup tags. Essentially, XML allows the author to define markup tags for special purposes as long as those tags conform to certain HTML syntax conventions. The W3C press release states the following; "XML is primarily intended to meet the requirements of large-scale Web content providers for industry-specific markup, vendor-neutral data exchange, media-independent publishing, one-on-one marketing, workflow management in collaborative authoring environments, and the processing of Web documents by intelligent clients. It is also expected to find use in metadata applications. XML is fully internationalized for both European and Asian languages, with all conforming processors required to support the Unicode character set. The language is designed for the quickest possible client-side processing consistent with its primary purpose as an electronic publishing and data interchange format."

The XML tags defined for the MSC Acumen "drive pages" are used to describe a simulation process work flow. Tags such as <defsteps>, <step>, <lrule>, and <dialog> describe the various steps of the process, the logic to follow for finding the first display dialog in a step, and the various dialog displays for each step. A <dialog> tag may contain attributes defining PCL functions to invoke. The actual HTML packet displayed for each dialog is listed as an <HTML> sub element to each <dialog>. This represents a powerful use of XML. Not only does it capture process knowledge in documentation form, it serves to actively drive and control the process.

Advisor Tag


<advisor>
Description:
Advisor is the top level element and contains optional defsteps and one or more step elements. All drive pages are delimited by <advisor> and </advisor> tags.
Elements:
<defsteps>	Optional
<step>	Required

Remarks:

<defsteps> elements are only made use of on the “Home” Step-1 and “nextpage” drive pages. The Step-1 drive page is defined by the ACUMEN_APPLICATIONS environment variable. The “nextpage” home drive page for steps 2-n is defined by the NEXTPAGE string user response variable stored in the State Table during the execution of Step-1.

Example:

None

Defsteps Tag


<defsteps>
Description:
Defsteps contain one or more ds elements.
Elements:
<ds>	Required	One or more <ds> tags are required to define the steps.

Remarks:

<defsteps> elements appear on “Home” “Step-1” or “Nextpage” drive pages only.

Example:

<defsteps>

  <ds stepid=”2.” steplabel = “Acquire Geometry” > </ds>

  <ds stepid=”3.” steplabel = “Geometry Check, Repair” > </ds>

  <ds stepid=”4.” steplabel = “Geometry Idealization” > </ds>

...

</defsteps>

Ds Tag


<ds>
Description
<ds> elements define the IDs and descriptions for analysis steps that will appear in the UI form main step selection box.
Attributes:
stepid	Required
steplabel	Required

Remarks:

<ds> elements are only included within <defsteps> and </defsteps> tags.

Example:

See example for <defsteps>.

Step Tag


<step>
Description:
<step> tags are used to contain the work flow description of each defined step of the process
Attributes:
stepid	Required
stephelp	Implied
Elements:
<uresponse>	Required
<lrule>	Optional
<dialog>	Optional

Remarks:

<step> tags corresponding to each step ID defined in the <defsteps> list must exist on the same “Home” drive page. Automated link rules <lrule> or other next_dialog calls can transfer control to sub-pages. Sub-pages are separate physical files. A “page” in this context refers to a physical file. <step> tags must also exist on sub-pages. The step IDs used on sub-pages are arbitrary and can differ from the IDs on the “Home” page.

The stephelp attribute to the <step> tag can reference either a local file (relative or absolute path) or a http address. For relative path references, the home drive page directory defined by the environment variable ACUMEN_APPLICATIONS is appended onto the beginning of the relative path.


Important:	Because of parsing issues, the format for http references needs to be “http_//www....” instead of http://www....”.

Example of a relative path for stephelp:

<step stepid = “2.” stephelp = “helpdocs/st2help.html”>

  <uresponse>

  <response name =”thickness” type=”REAL”> </response>

  <response name =”complete” type=”STRING” values=”C,X” readonly> </response>

  <response name =”geomsource” type=”STRING” vlaues=ug,express” readonly> 		</response>

  </uresponse>

...

</step>

Example of an absolute path for stephelp:

<step stepid = “2.” stephelp = “d:/testing/step_test/helpdocs/st2help.html”>

...

</step>

Example of a web address for stephelp:

<step stepid = “2.” stephelp = “http_//www.macsch.com/helpdocs/st2help.html”>

...

</step>

UresponseTag


<uresponse>
Description:
Establishes a set of variables for each step tag to support the “Quick Review” functionality.
Elements:
<response>	Optional	A uresponse tag may contain zero to many response tags. The response tag declares a user reponse variable as stored in the State Table to display on the Quick Review form.

Remarks:

All user response variables that are utilized in automated link rules (within <1rule> tags) must be listed in the <uresponse> tags.

This tag supports the “Quick Review” functionality. Note that variables may be stored in the State Table with out listing them in <uresponse> tags.

Example:

<uresponse>

  <response

    name = “geomsource”

    type = “STRING”

    values = “ug,catia,proe”> </response>

  <response

    name = “thickness”

    type = “REAL”> </response>

  <response

    name = “complete”

    type = “STRING”

    values = “C,X”

    readonly = “yes”> </response>

</uresponse>

Response Tag


<response>
Description:
The response tag is associated with a <uresponse> tag. It defines variables to display for the “Quick Review” functionality.
Attributes:
NAME	Required	Name of the variable.
TYPE	Required	The type of the variable, which must be scalar: STRING, REAL, INTEGER
VALUES	Implied	If the type is STRING, a list of values is required, separated by comma delimiters.
READONLY	Optional	This attribute will prevent the user from making value changes with the Quick Review functionality.

Remarks:

None.

Example:

See example for <uresponse>.

Lrule Tag


<lrule>
Description:
Automated Link Rules are used to allow the drive page interpreter to make automated selections of hypertext like links and locate the correct initial dialog packet for an analysis step.
Attributes:
ruleid	Required	An identifying rule ID, 8 characters maximum.

Remarks:

The only boolean operators allowed are == and !=. The current implementation does not allow for nested IF statements, or logical operators AND or OR. Note that AND or OR logic operations are accomplished by the IF conditional in one <lrule> block giving the destination address as another <lrule>.

The only statements that are allowed to follow the first IF are: an address statement page(“XXX”).step(“XXX”).dialog(“XXX”); an ELSE IF statement; or an ELSE statement. There can be any number of ELSE IF statements.

If a boolean match is NOT found for a link rule, the control drops down to the next <lrule> tag or <dialog> tag found below for this step on this page.

Each full address destination consists of three fields. The first address field (page) is an XML drive page file name. A file name or a full page name is allowed. The home drive page directory as defined by the enviroment variable ACUMEN_APPLICATIONS is appended to the front of the filename unless a slash (/) is the first character of the field. A period (“.”) is an acceptable filename which stands for “this page” (the current drive page that contains the link rule). The second address field (step) is a 4 character maximum step ID. A period (“.”) is also an acceptable step ID entry which means “this step”. The third field (lrule or dialog) is a link rule or dialog address of 8 characters maximum.

All state table variables listed in logic operations within <lrule> tags must also be listed in <response> sub-elements to the <uresponse> tags for the respective steps. This allows the automated link rule interpreter to determine the variable type that is used in the logic operation.

Example:

<lrule ruleid=”tagid1”>

    if (step(“stepid1”).uresponse(“varname1”) == “somevalue”)

        page ( “filepath”).step(“stepid2”).lrule(“tagid2”);

    else if ( step(“stepid1”).uresponse(“varname2”) != 4)

        page ( “filepath”).step(“stepid3”).dialog(“tagid3”);

    else page(“filepath2”).step(“stepid4”).dialog(“tagid4”);

</lrule>

Dialog Tag


<dialog>
Description:
The dialog tag has required and optional attributes which support an enhanced UI functionality. All character data assigned to attributes are delimited by quotes (“). The attribute declarations are NOT separated by a comma delimiter. The attributes for a dialog tag can be in any order.
Attributes:
dlgid	Required	The dialog id. 8 character maximum.
inputid	Required	The PCL Function Definitions file look up ID associated with this dialog. 32 character maximum. An assigned value of “null” denotes that no “Inputs Box” functionality is used, and no widgets for user interaction will be displayed.
quedlg	Optional	This is the address of a queued dialog to be displayed in the “Dialog Box” after the Apply Inputs button is selected and after the associated “Inputs Box” referenced PCL functions are executed. The address consists of three fields: 1) the page file, 2) the step ID, 3) the dialog ID. Note that the # is the delimiter. A dot (.) indicates “this one”. For example “.#.#next_dia” would indicate this file, this step, next_dia dialog. Note that if inputid = “null” then this attribute is not used.
errordlg	Optional	This is the address of a queued error message to display in the “Dialog Box” in the case input function returns an error code after the “Apply Inputs” button is selected. The address consists of three fields: 1) the page file, 2) the step ID, 3) the dialog ID. Note that the # is the delimiter. A dot (.) indicates “this one”. For example “.#.#errormsg” would indicate this file, this step, errormsg dialog.
initftn	Optional	This attribute is set equal to a character string representing any number of requested PCL function calls with fixed value arguments. The PCL calls requested by the tag are dialog precursor calls made at the time the new dialog is displayed in the “Dialog Box”.
queftn	Optional	This attribute is set equal to a character string representing any number of queued PCL function calls with fixed value arguments. The PCL calls requested by the tag are executed after calls made by the “Inputs Box” referenced function. Note: If inputid = “null” then this attribute is not used. Note: Two conditions are necessary for calls under this to be invoked; (1) inputid must not be = “null”, (2) the PCL function call specified by inputid must return a success status, or no status checking is called for.
exitftn	Optional	This attribute is set equal to a character string representing any number of requested PCL function calls with fixed value arguments. The PCL calls requested by the tag are executed right at the time the dialog is exited from the “Dialog Box”. Note: Even if inputid=”null”, this attribute is still used. Function calls listed under this attribute are invoked regardless of success or failure status from any inputid listed calls.
undo	Optional	This attribute is set equal to a character string representing any number of requested PCL function calls with fixed value arguments. The PCL calls requested by the tag are executed when the user hits the “Dialog Backup” button, and this <dialog> is displayed as a result.
Elements:
<returnerror>	Optional	This element will override the errdlg attribute and more precisely handle various return value conditions.
<HTML>	Required	This element will provide a text and/or graphics display to the UI form “Dialog Box”.

Remarks:

The <returnerror> element is allowed within <dialog> tags.

Example:

<dialog dlgid = “start”

  inputid = “ugfileopen”

  quedlg = “.#2.#ug2”

  errordlg = “errors/ugimport.xml#stp1#err1”

  initftn = “FUNC:gu_fit_view”

  queftn = “F:AASTATE.record_ur_string;STR:geomsource;STR:ug;

            F:AACHECK.nas101_st2;

            F:AANAV.step_wrapup;”

  exitftn = “F:ga_view+aa+set;R:30;R:30;R:0

  undo = “F:AANAV.undo_ugfile”>

<returnerror

  retvalue=1

  retdlg = “.#2.#er1”>

<returnerror

  retvalue=2

  retdlg = “.#2.#er2”>

<HTML

Please select the CAD file from the list below.

</HTML>

</dialog>

Returnerror Tag


<returnerror>
Description:
This sub element to the <dialog> tag provides a precise way to handle different return conditions from the execution of a PCL function associated with the “Inputs Box” functionality. A non-zero return directs display of different dialogs depending upon the return value.
Attributes:
retvalue	Required	Possible integer return value from the referenced PCL function
retdlg	Required	Address of the <dialog> to display for this return value.

Remarks:

Any number of <returnerror> elements can be listed for the various integer return values. If the return value is a non-zero value not covered by <returnerror> elements then the <dialog> referenced by the errordlg attribute of the current <dialog> will be displayed. If no errordlg attribute was listed in this case, then a default platform software supplied error message is displayed.

Example:

See <dialog> example.