Sunday 29 March 2009

New Release 1.6.4 Available

Fixes Made

2717291 Add parameter for dictionary create - cxf-2-dictionary 
2717289 Add parameter for cam-2-xsd export 
2715423 Enhance dictionary create tool to support CCTS 
2712586 Dictionary format include CCTS labels 
2692006 Hinting system not matching on attributes 
2690379 Some patterns causing error in random func 2nd parm 
2591499 Add XSD generation options to export xsd

Thursday 22 January 2009

Sunday 18 January 2009

New Release 1.6.3.2

A major error was foundin the 0.9.9.10 release of CAMV which prompted this quick release. In also includes a number of XSLT fixes.

Bugs Fixed

  • 2517859 Loading files and detecting mixed content
  • 2516066 xsd:float base type for restriction
  • 2513927 Add UID to dictionary and cross-ref' tools
  • 2513923 Dictionary merge content not always working
  • 2513916 Skip non xsd: content - Oracle designer XSD tool usage

Wednesday 14 January 2009

CAMed 1.6.3.1 released

Although 1.6.3 of CAMed was announced two days ago, a new release which replaces 1.6.3 has been released today 14th Jan 2009.  The release is the same code base as 1.6.3 but repackaged and uploaded as 1.6.3.1.
One major new introduction in this release is the inclusion or the correct JRE required for it to run.  This increases the download time, but should prevent installation problems.

  • Windows Installer for 1.6.3.1 of CAMed. download
  • Zip file of 1.6.3.1 of CAMed. download

Monday 12 January 2009

Parameters, Variables and Context

CAM has a very subtle extra feature over its bigger challenger XML Schema.  This is the ability to change the rules that are applied at run-time, by using parameters.
These come in two forms global and local.  
global parameters are using to pass in a value that can be interpreted by conditional rules or contexts.  If for example a parameter existed called 'processing-style' that had a couple of options strict and lax, then a pair of context could be defined with the respective conditions of $processing-style = 'strict' and $processing-style = 'lax'.  Under each of these could be a set of rules that would be appropriate for the processing that is required.  By setting the value of the processing-style parameter at runtime the rules applied can be drastically changed without changing code.
local parameters are similar in that they are used to affect the rules that are applied, however, their values are derived from the contents of the xml file that is being processed.  This means that they have an xpath associated with them to derive a value.  local parameters can be re-evaluated by invoking the evaluateVariable action.  This cause the xpath of the parameter to be reparsed and a new value derived in the context of the node which contained the evaluateVariable action.  This can be useful when repeated sections of xml exist, but their contents are different.  For example the rules for for an order-line in a purchase-order could be different based on the item being ordered.  This could be achieved by evaluating the value of the parameter when a new order-line element is encountered.  
(evaluateVariable replaces the CAM specification scope attribute of a context node.)

In the future the ability to select the structure being processed will also be possible by simply choosing it using a parameter.  This would allow the run-time selection of the contents to be drastically changed, again without programming.

CAMed 1.6.3 Release

Changes
This release is bug fix release.  The major changes are in the area of tidying up areas such as the parameter view to make sure that incorrect parameters are less likely.  Also CAMV should now raise exceptinos for things like mixed content and parameter issues.

Quite a few changes have occurred within the xsd2cam stylesheets.  This should eleviate some of the minor niggles that remained.


Bugs Fixed

2500080       setchoice handling needs updated to match name() rule
2499432       Mixed content ignored
2496940       Parameter causes SaxonApiException
2496296       xsi:nil incorrectly checked
2496291       any is not working
2494648       Erroneous "template is null"
2493610       Exception when reading string pattern in XSD
2488827       Dictionary merge - mask detail update handling
2488824       Test case generation - short data type handling
2488820       Tabular Report - choice() on name()= items


Feature Requests

2492737 Shortcut keys needed

Wednesday 7 January 2009

Dividing and conquering with CAM

It can sometimes be difficult to  know how to manage some of the processing of complex structures.  Where do you put rules?  What is a context used for?  When should I use a condition and when should I use a context node?

  1. Default Rules - these are rules that are applied to the template first and can be over-ridden either by Context Nodes or conditional rules.
  2. Context Nodes - These are used to divide rules up into groups.  Typically they are groups of rules that will apply when a particular condition is true.  These conditions might simply be the existence of a node in the tree, or a node having a particular value.  
  3. Conditional Rules - This is used when a condition is applied to a single node.  Typically these are rules that check values of the node in question and apply, for example, a mask based on its length.
Rule processing is done by first applying the Default Rules to the template.  These rules are unaffected by the content of the XML file being checked.  They can therefore be associated with nodes in a pre-processing stage when a template is read in.  Context and conditional rules are applied only when an XML file is being processed.  The processor looks through each node in the template structure in question and checks it against the XML nodes it finds in the input document.  If a node has conditional rules applying they are applied and then the checks are done based on the content of the XML file.  If a node does not exist in the XML file any associated conditions are still checked but in the context of the parent node.  The reason for this is that a condition might be designed to mark a node as excluded and that might explain why the XML does not contain the node.

CAMV in particular does not distinguish between Context and Conditions.  It combines the conditions defined for the Context with any conditions found on the rule.  This combination is done during the compiler stage.  It is possible to see this by using the CAMed> Tools menu> Compile Template option.  This will output a .cxx file which is a simple compiled template that is consumed by the CAMV processor.

JCAM (in the process of being withdrawn) took a different approach.  Every time an XML file was submitted for processing the template was read in and a stage called trimming was run.  This first applied the default rules and then using the XML file applied the context and conditional rules.  If nodes were repeated JCAM duplicated that part of the tree and then applied any rules.  This trimming process had some problems, for example marking a node as excluded meant it was removed from the tree altogether, making it impossible to recreate it should a conditional rule mark the node as in use.  CAMV gets round this by holding both a default set of states and an applied set that is used each time a node is encountered.  Should an excluded node be marked as in use the flag in the applied settings is changed from excluded = true to false.

Rule of Thumb for Use of Context
If a condition is based on the structure of the document it will probably be best to create a context node.  Secondly it is possible to nest context nodes to handle complex compound conditions.  This sometimes makes the creation of the template easier - hence dividing to conquer!