All:

For those of you who depend on SYMCLI XML Element output to parse CLI output, be advised of the following:  the ...\SYMCLI\interfaces\xml\docs\SymCLI_ML_Element.xsd documents are entirely irrelevant to actual XML_ELEMENT output provided with your version of Solutions Enabler. 

An SR I filed on this issue revealed that the XSD's contained therein have remained untouched since 2006.  The SR also revealed that are no plans to update the schema document.

Try it yourself:  using the schema given to us customers (a 'diff' on the xsd provided with SE 7.3.2.2, 7.5.0, 7.5.0.1, 7.6 shows it's the same file), try to validate any content of any XML Element output from any symcli command.

For example: 

SET SYMCLI_OUTPUT_MODE=XML_ELEMENT

symcfg -sid XXXX list -fa all -v all > symcfg_example.xml

Attempts to validate the above 'symcfg_example.xml' file against the schema provided with Solutions Enabler produces:

ERROR: Element 'led_status': This element is not expected. Expected is one of ( total_mem_boards, total_cap_in_mb, pav_mode, config_changed, discovered, total_patches, permanent_patches, temporary_patches ).

ERROR: Element 'registered_build': This element is not expected. Expected is ( date ).

ERROR: Element 'Symmwin': This element is not expected.

I then asked for information on how to determine what has changed in the XML structure for commands, especially as I consider upgrading from one s/w release to the next.  The answer I received is that there are no plans to remove "XML Element Support", and, importantly, that there are also no plans to fix the schema.

So, instead of simply using a master schema to help me process any XML document output by whichever command I need to execute, storage admins in the trenches (like myself) must now recommend a multi-step process:

1. Determine the CLI command you intend to run.

2. Run the command and produce an XML output file.

3.  Use, for example, tools such as 'trang' to generate unique XSD's for each of your commands. 

4.  In the case for some symaccess commands, for example, be aware that each variant of argument strings may or may not produce an XSD that conflicts with XSD's produced by other variants on the same command.  Don't be fooled that a massive XML document from a 'list -all -v' flavor of a symcli command will produce an XSD that will validate documents produced by more specific arguments to symcli commands.

5.  Use the generated .XSD (or relax-ng, whatever you prefer) in your processing. 

Be aware that element tags are not canonical for all the commands contained within a version of SE.  There's enough inconsistency in element tag names to eliminate any feasible generative approach to symcli XML output processing.