[DFDL-WG] XSL-style SmartLengthString Sample

[RPost]

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/20080617/de6d08c6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmartLengthStringXSLSample.doc
Type: application/msword
Size: 61440 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dfdl-wg/attachments/20080617/de6d08c6/attachment-0001.doc