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: 1. Separate input/parse considerations from output/unparse. 2. Provide for all physical elements without requiring them to be in the visible infoset 3. Provide for multiple/nested layers 4. Allow for multiple transforms to be performed even within a single layer. 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