Hi,
Attached is a doc that describes a (syntax-deprived) version
of Mike’s SmartLengthString example that is done more in a style that
combines XML and XSL. It would use XML for the visible infoset and element
declarations but an XSL style for the transforms.
It attempts to:
I still have scalability concerns with using one outputValueCalc
(or input) expression if multiple or complex transformations need to be done.
The idea is to use a simple structure that can be nested to
get the complexity that is needed. Here is an excerpt from the doc but the
formatting will probably get out of whack:
<xs:complexType name="smartLengthString"
...other attributes...>
<xs:sequence>
<hiddenStructure> --
the annotations and transforms between the physical and logical layers
<hiddenElements>
.
. . one or more elements . . .
</hiddenElements>
<inputLayer>
.
. . The transforms and lower layer elements needed to produce the higher-layer
Elements and ultimately the infoset informational values.
</inputLayer>
<outputLayer>
.
. . The transforms and higher layer elements needed to produce the lower-layer
elements and ultimately the physical layer values.
</outputLayer>
</hiddenStructure>
<visibleElements> --
the infoset as experienced by the user
</xs:sequence>
</xs:complexType>
As you can see I took a lot of liberties with the syntax to
try to make it easier to see the structure I am using. The ‘hiddenStructure’
element is what contains the equivalent of the <xs:annotation><xs:appinfo>
from the example.
The hidden elements are equivalent to elements in the
example that are not in the public infoset.
The inputLayer contains whatever is needed (including nested
inputLayers) for parsing. Likewise for the outputLayer and unparsing.
Here is a skeleton inputLayer:
<inputLayer>
<layerElements>
<!--
These are lower layer elements that the transforms use to produce the
hiddenElements in the layer above. In many cases no elements will be needed
since
the transforms will get their input directly from the physical layer.
-->
</layerElements>
<transforms>
<!--
These transforms transform the <layerElements> above (or the physical
bits and
bytes) and produce the hiddenElements. As many transforms can be used as needed
and they can be specified as an ordered list
-->
<transforms>
<inputLayer>
<!--
Next nested layer if needed - can be nested to any depth needed. The nested
layer
would create the values of the layerElements in this layer. -->
</inputLayer>
</inputLayer>
There is a section for elements specific to this layer;
somewhat akin to intermediate working variables or intermediate calculations.
Another section is for an ordered list of transforms. This
allows for as many or as few as needed but provides clean separation between
them. The first transform might create the value of the ‘lengthFlag’
hidden element. The next transform could then use the lengthFlag value to
extract the logicalLength value and so on.
It sure seems to flow ok but maybe that is just in my head.
The nested ‘inputLayer’ allows for a chain of
transforms to be created. The nested inputLayer could create values for this
layer’s layerElements and get it’s input from either another nested
layer or from the physical layer itself.
If the doc does nothing more than help solidify your
thinking about how to get where you want to go it will have done it’s
job.
By the way, thanks for the excellent example Mike.
Rick