• Run the Model
• Workflow Example
• SharpHog Model
• Spot Growth Database
• The X-Factor
• Disclaimer
• SharpSpb 101: Xml, Xsd, Xslt, and XPath
• SharpSpb Xml
• SharpSpb Xsd
• SharpSpb Xslt
• Verbosity
• Shaking Down the Xslt

Throughout this site I keep saying this or that X-including acronym is an "international standard". Specifically, these are the international standards adopted by the SharpSpb project in both the Spot-Growth Database information clearinghouse, and the SharpHog Southern Pine Beetle infestation Model:

• XML - eXstensible Markup Language is a set of rules for structuring information, and files that obey this specification
• XSD - XML Schema Definitions describe concretely the value-types, ranges, & data-relationships in a particular XML file
• XSLT - eXtensible Stylesheet Language Transformations style or transform the data in an XML file
• XPath - XML Path Language is the specification for a shorthand used to traverse and examine an XML tree.

This information does beg a couple questions.

Q. What Gives With All the 'X's?

A. These standards were developed in the 1990s, when 'X' was süper-cool, by members of the--second-greatest--Generation-X.

Q. What's the big deal?

A. Standards are good. Everybody can share and speaks the same language--the definition of a healthy scientific environment.

Q. OK, where can I learn more, without the snark?

A. The Technical Specification articles sound right up your alley.

XML: eXstensible Markup Language

Xml is disingenuous. It stands for eXstensible Markup Language, but is more of a grammar than a language, technically a specification consisting of a syntax and some reserved characters, "<,>,%,&".

Unlike a script file or program file, Xml files aren't meant to acheive anything (typically, though the flexibility is limitless, and many specific implementations of Xml, such as Xslt itself, do achieve things). Xml is distinguished from scripting languages and programming languages--it is a "Markup" language.

Xml is an enforced heirarchical structure, wholly nested elements within elements within one containing element and is easily visualized as information tree with a root node, branch nodes and terminal nodes.

Individual elements, or nodes of the tree, in an Xml file are denoted (marked-up) by an opening marker and a closing marker--known as tags. Xml does not enforce or suggest names for the nodes, that's where you start packing in more useful information. So if we had a number, 17, and in our scheme of things that was an age, a reasonable way to mark-up the number in an element with opening and closing tags would be:

<age>17</age>

The opening <age> tag signifies the beginning of the element, 17 is the value of the element, & </age> is the closing tag--distinguished by the slash.

If this age were the age of a person, as opposed to a car or a tree, a reasonable refelction of this information might nest the age node inside a person node

<person>
  <age>17</age>
</person>

If information exists about one person, it probably exists about other people, and they are different people.

<people>
  <person name='Anna'>
    <age>23</age>
  </person>
  <person name='Betty'>
    <age>17</age>
  </person>
</people> 

Becasue the data has been structured to Xml specification, a tool consuming the snippet doesn't need to know what 'people' are to tell you how many persons exist, or what 'age' means to see which 'person' has the lowest number.

Here is a complete Xml document (includes document-type declaration at the top), which we will use in our exploration below.

<?xml version="1.0" encoding="utf-8"?>

<people>

  <person name='Anna'>

    <age>23</age>

    <gender>female</gender>

  </person>

  <person name='Betty'>

    <age>17</age>

    <gender>female</gender>

  </person>

  <person name='Clark'>

    <gender>male</gender>

  </person>

</people>

Terms used for the parts of an Xml file include, "tags", "elements", "values", and "attributes".

Tags form Elements; the node from opening tag through contained value through closing tag is an element.

Elements have Values; the value of an element is whatever is contained within its opening and closing tag, and may be a number, a string, or more Xml.

In addition to values, elements have Attributes. Here, the <person> elements have been given a "name" attribute.

Attributes also have values, which are always text-strings (possibly numeric), but not nested Xml.

Xml errors are invariably errors of syntax. Elements not wholly contained in other elements, elements with opening but no closing tag, mssing quotes and quote mis-matching, general typos, and misuse of reserved characters.

Here are two more Xml snippets. Examination will show that they carry the same information as our original.

<!--  //  This syntax 

      //  <tagname optionalattribute='value' /> 

      //  is called a self-closing tag. Elements 

      //  with no Value (no information between

      //  the opening and closing tags)

      //  can close themselves using 

      //  the <.../> syntax

         -->

<!--  //  i.e. <tag></tag> is equivalent to <tag/> . 

         -->

<!--  //  Elements carry information in their name &

      //  otherwise just by existing, 

         -->

<!--  //  Elements can have Attributes with Values,

       //  even if the Element itself hasn't a Value.

         -->

<people>

  <person name='Anna' age='23' gender='female' />

  <person name='Betty' age='17' gender='female' />

  <person name='Clark' gender='male' />

</people>

<list name='People'>

  <item type='Person'>

    <item-info name='Name' value='Anna' />

    <item-info name='Age' value='23' />

    <item-info name='Gender' value='Female' />

  </item>

  <item type='Person'>

    <item-info name='Name' value='Betty' />

    <item-info name='Age' value='17' />

    <item-info name='Gender' value='Female' />

  </item>

  <item type='Person'>

    <item-info name='Name' value='Clark' />

    <item-info name='Gender' value='Male' />

  </item>

</list>

The Xml specification allows data to be marked-up however the consumer or creator finds most useful But eventually a structure must be settled on, and a means for communicating that structure to other entities. This is where XSD, Xml Schema Definitions, come in--as seen in the next section.

XSD: Xml Schema Definitions

XML Schema Definition(XSD) files describe the information contained in the certain data (XML) files. XSD files, as is typical, are themselves valid Xml (closed elements nested inside an eventual single root node). The valid names for elements, valid names for their attributes and attribute values, and the valid element values are strictly defined, providing the semantic framework for defining and describing the structure of some exterior Xml.

Consider this short snippet from earlier:

<people>
  <person name='Anna'>
    <age>23</age>

    <gender>female</gender>
  </person>
  <person name='Betty'>
    <age>17</age>

    <gender>female</gender>
  </person>
</people> 

Even the most clever of generic algorithms could only deduce, from this snippet, limited information about what 'person's and their properties are. For example, a tool may be able to tell you which of the two persons it is aware of has the lower age, the tool could not say with definity that all persons must have an integer age. Or a name. No tool looking at this snippet could reasonably be expected to deduce that every person has a gender, and (for purposes of illustration) that 'gender' has only two valid values.

For these sorts of relationships--ones not implicit in the structure and content of the Xml--a specification has been developed to define the data-types, valid values, maximum and minimum occurrences, key-values and data relationships: XSD-XML Schema Definitions.

Defining this information rigorously allows tools to utilize the xsd in achieveing goals. For example, in Visual Studio when coding in C-Sharp, the SpotGrowth & SPBModel XML Schema Definitions (XSDs) allow the Intellisense to provide the names of the columns in the tables--removing need to constantly reference values indirectly through checking if their name equals one required (and typed in each time e.g. "feildNameWrong")--see the article on using the StatesData schema.

Let us describe in English what we want our people Xml to be.

<people> will be a collection of zero or more <person>s. A <person> must have an attribute called 'name' with a text value. A <person> may or may not include an <age>, but if the <age> does exist, it exists once, and is an integer between 0 and 120. All <person>s must contain a single <gender> element. <gender> elements, for purposes of illustration, can only have the strings 'male' or 'female' as their value.

Here is the equivalent information in an XSD schema. Notice that while one may not know immediately how to go about creating a particular new XML Schema Definition of their own, it is easy to examine an existing XSD and discern its meaning.

<?xml version="1.0" encoding="utf-8"?>

<xs:schema

    xmlns="http://tempuri.org/XMLSchema.xsd"

    xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="people">

    <xs:complexType>

      <xs:choice minOccurs="0" maxOccurs="unbounded">

        <xs:element name="person" >

          <xs:complexType>

            <xs:all>

              <xs:element name="age" minOccurs="0">

                <xs:simpleType>

                  <xs:restriction base="xs:integer">

                    <xs:minInclusive value="0"/>

                    <xs:maxInclusive value="120"/>

                  </xs:restriction>

                </xs:simpleType>

              </xs:element>

              <xs:element name="gender">

                <xs:simpleType>

                  <xs:restriction base="xs:string">

                    <xs:enumeration value="male"/>

                    <xs:enumeration value="female"/>

                  </xs:restriction>

                </xs:simpleType>

              </xs:element>

            </xs:all>

            <xs:attribute name="name" type="xs:string" use="required" />

          </xs:complexType>

        </xs:element>

      </xs:choice>

    </xs:complexType>

  </xs:element>

</xs:schema>

XML Schema Definitions are really, really handy. In addition to the two main external schemas composing the SharpSpb project--SpotGrowth.xsd & SPBModel.xsd--SharpSpb uses four additional schemas internally; StatesData.xsd, FrameConfig.xsd, TemperatureData.xsd, and ValueRequest.xsd. TemperatureData and StatesData are strongly-typed into the ado.net structure, freeing up their use in C-Sharp as shown above. FrameConfig and ValueRequest don't need the .NET DataSet super-functionality, and have accordingly simpler definition files.

XSLT: Xml Stylesheet Language Transforms

All Modern Computer Applications Use Xml.

Office applications store their documents in Xml. Image editing applications store settings. Email application check RSS feeds (xml!) and backup accounts in Xml. SharpSpb uses Xml throughout. With so many applications using particular schemas of Xml to store their data, a language dedicated to transforming one sort of Xml into another sort of Xml would be extremely useful.

That's where Xslt comes in.

It should be noted that Xslt can transform Xml into anything--it is just most commonly into more Xml. Other common uses include transforming to not-strictly-xml-compliant Html, or into a series of lines INSERTing data into a SQL table. Xsl Transforms can return a single number or word--It just is almost always easier to handle as xml: 'resultvalue' as opposed to '<Result>Value</Result>'.

The SharpHog SPB Model uses Xslt Equations to calculate Values from a Value Request every hour of every day simulated.

Recall Our People.xml

<?xml version="1.0" encoding="utf-8"?>

<people>

  <person name='Anna'>

    <age>23</age>

    <gender>female</gender>

  </person>

  <person name='Betty'>

    <age>17</age>

    <gender>female</gender>

  </person>

  <person name='Clark'>

    <gender>male</gender>

  </person>

</people>

XSLT Asks:
What do you want, & How do you want it?

XSLT accepts input XML, finds the important bits, processes them through anything this side of computability, then delivers them in a tailored-to-application format.

Say I want to show all the information in <people> to a web-ste visitor. Using the People.xsd schema and the <people> Xml snippet as reference, I created an Xslt file (using Visual Studio, but any editor will do) which will Transform the data from our snippet into an Html definition list for display on a web-page.

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet

  version="1.0"

  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

  xmlns:msxsl="urn:schemas-microsoft-com:xslt"

  exclude-result-prefixes="msxsl">

  <xsl:output method="html" indent="yes" />

  <!--  //    This match-expression '/' will match the root node of the input xml, 

        //    whatever it may be named -->

  <xsl:template match="/">

    <!--  //    We'll list the persons using an Html definition list -->

    <dl>

      <!--    //    For each person in people, sorted by age-->

      <xsl:for-each select="/people/person">

        <xsl:sort select="age"/>

        <!--  //    Apply template to the person -->

        <xsl:apply-templates select="." />

      </xsl:for-each>

    </dl>

  </xsl:template>

  <!--  //    Matches person elements from the sample people.xml -->

  <xsl:template match="person">

    <dt style="color: Green;">

      <xsl:value-of select="@name"/>

    </dt>

    <dd>

      <xsl:text> (</xsl:text>

      <xsl:value-of select="gender"/>

      <xsl:text>) </xsl:text>

    </dd>

    <xsl:choose>

      <!--  //    If an age exists for this person, include it-->

      <xsl:when test="age">

        <dd style="color: Blue;">

          <xsl:value-of select="age"/>

          <xsl:text> years</xsl:text>

        </dd>

      </xsl:when>

      <xsl:otherwise>

        <dd style="color: Red;">

          <xsl:text> Age Unknown</xsl:text>

        </dd>

      </xsl:otherwise>

    </xsl:choose>

  </xsl:template>

</xsl:stylesheet>

Try to figure out what the result might look like, then click here

XPath

XPath is used to navigate and examine an Xml document and resembles filepaths or urls with wildcards and conditions.

Congratulations, you now meet the requirements for SharpSpb 200 Level Articles