Rick , In your document you propose this: Here is an excerpt from Mike's sample: dfdl:inputValueCalc="{ if (../lengthFlag = '1') then ../fourByte else ../oneByte }" And an excerpt from above using XSL-style syntax: <transform> <xsl:variable name="../logicalLength"> <xsl:choose> <xsl:when test="../lengthFlag=1"/><xsl:value-of select="./fourByte"</xsl:when> <xsl:otherwise><xsl:value-of select="./oneByte"/></xsl:otherwise> </xsl:choose> </xsl:variable> </transform> And suggest that the XSL version is somehow more familiar and more standard. I definitely disagree. Other than the curly brace surround, what is in between is a subset of w3c standard XPath 2.0. Given that XSL uses XPath expressions also, the following is legal XSL now, since XSL subsumes XPath: <xsl:variable name="../logicalLength"> <xsl:value-of select=" if (../lengthFlag = '1') then ../fourByte else ../oneByte "/> </xsl:variable> This is just a more verbose equivalent to the curly brace surround. Given this, it is clear that we don't need both xsl if-then-else logic and XPath if-then-else logic. We can choose just one. Since we need the path language no matter what I don't see a reason to mess with XSL further. This is also a bit of a taste and style issue rather than one of substance. I.e., I find the XPath style which is more dense, far more readable and comprehensible than the xsl stuff, which is to me, so verbose as to be impenetrable. XSL syntax is really the abstract syntax tree of a language, rather than a reasonable language for humans. .mike Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2100 | 504 Totten Pond Road, Waltham MA 02451 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of RPost Sent: Tuesday, June 17, 2008 8:36 PM To: dfdl-wg@ogf.org Subject: [DFDL-WG] XSL-style SmartLengthString Sample 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