Following on from Scotts fine talk today - some examples of how a graph model can be realized as a component model - via XPath conceptual metaphor - that references specific nodes in a node tree.
There may even already be a conceptual view over XPath (would make Xpath easier to do clearly) - and hold that the possiblity of going straight from the graph view - into generated Xpath logic...
Scott gave some supplychain scenario examples in his slides.
Here's an excerpt from Michael Sorens DEVX article with how this can be done manually in XML today using CAM with some similar examples.
Thanks, DW
============= Excerpt from DEVX article ============
Cross-Node Conditional Validation
XML Schema's conditional expressions are available only through regular expressions. CAM extends this with cross-node conditional validation, where you specify an action on one node based on the value of a different node. For example, suppose that items with a part number of 123-678 are customized for customers in the state of Washington. If that part number shows up on a purchase order for a customer from a different state you would want it to be flagged as an error. Recall that CAM conditions and actions select nodes by standard XPath. Thus, you essentially already know how to do this; in prior examples the condition always referred to an XPath of "." (the current node). But if you change this to some other node, with a constraint such as that shown below, you now have a cross-node validation rule.
<as:constraint
condition="//Item/@pno = '123-678'"
action="restrictValues(//shipTo/state,'WA')" />
The term cross-node fits better than cross-element because "node" is the more general XML term. An element is a node and an attribute is a node. The XPath conditional expressions aren't limited to XML element nodes; you may also (as in the example above) reference attribute nodes.
Structure Variability
Cross-node validation is impressive. But discovering that you can dynamically modify what constitutes a valid structure is dazzling. Such modification provides tremendous flexibility-but requires learning a few intricacies. Here are a few examples.
- Example 1: Assume a purchase order includes an optional color attribute. Further assume that the purchase order includes a tray number where the item is found in the warehouse. Items with color attributes don't need a tray number-the color is sufficient for picking the item. However, it is harmless if the tray number is provided. This constraint expresses these business rules:
<as:constraint
condition="exists(//Item/@color)"
action="makeOptional(//Item/TrayNumber)" />
- Example 2: Assume you have a purchase order that includes the total order weight, and that the purchase order also includes an optional freight carrier element. However, if the order weight exceeds 25 kg, then the purchase order must specify a freight carrier to transport the goods. That is, if the condition shown below is satisfied then the FreightHandler node must be present. This constraint expresses these business rules:
<as:constraint
condition="//Item/@weight > 25"
action="makeMandatory(//Item/FreightHandler)">
If you are following along with the working examples, you may find that constraints referring to other nodes (such as the preceding examples) may perform as advertised-or not. The results depend on your specific XML instance. Notice that each of the last three examples used the XPath // designator to start each selector. That selector locates any and all nodes that match the rest of the expression.