[DFDL-WG] XSL-style SmartLengthString Sample

Wed Jun 18 09:20:20 CDT 2008

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

  _____  

From: dfdl-wg-bounces at ogf.org [mailto:dfdl-wg-bounces at ogf.org] On Behalf Of
RPost
Sent: Tuesday, June 17, 2008 8:36 PM
To: dfdl-wg at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20080618/ba7a1ed3/attachment-0001.html 