I like this simplified version alot! Some questions:

1) In the VCalendar example, ProdID is an element with a dfdl:ref (typo
of dfdl:formatRef) to tns:folded, which contains dfdl:layer* properties.
But layering properties are only allowed on xs:sequence's. I assume this
was just an example from the old proposal that wasn't fixed up, and
should be something like this instead:

  <xs:sequence dfdl:ref="tns:folded">
    <xs:element name="ProdID" type="xs:string" dfdl:initiator="PRODID:"

Which raises a small issue with simple types: This layering transform
now applies to the initiator/terminator of the simple type. If you do
not want a layer to apply to those but only to the value, you'd need
make it a complex type with a "Value" element. I'm not sure this is a
big deal, but layering on simply types might get a little messier in
some cases if the initiators/termiantors shouldn't be transformed.

2) What happens with unused data in an overlying layer. For example:

Say we have something like

  <dfdl:defineFormat name="base64">
    <dfdl:format layerTransform="base64" layerLengthKind="explicit"
                 layerLength="8" ... />

    <xs:sequence dfdl:ref="base64">
      <xs:element name="foo" type="xs:string" dfdl:length="3" />
    <xs:element name="bar" type="xs:string" dfdl:length="3" />

Assume the data is this:


The first 8 characters are base64 encoded, and decode to "fooX". The foo
element would only consume three of those characters, so the last "X"
character would be not consumed by foo.

The length of the layer transform was 8 characters, so bar would start
parsing after that and consume the "bar" letters.

So what happens to the unconsumed "X" character? Is it just thrown away?
This seems consistent with how we treat a complex element with explicit
length where the children do not consume the full length. Or is this an
Runtime SDE? Related, on the unparse side, when we base64 decode "foo"
it is only 4 characters, but the layerLength is 8. Are pad characters
inserted to fill that out to 8? Do we need a layerPadCharacter and other
related pad properties?

- Steve

On 04/06/2018 04:10 PM, Mike Beckerle wrote:
> Never mind that one. I've simplified it even further:
> https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Data+Layering+for+base64+-+Super+Simplified
> ________________________________
> From: Mike Beckerle
> Sent: Friday, April 6, 2018 3:12:31 PM
> To: dev@daffodil.apache.org
> Subject: Simplified DFDL layering/base64 proposal
> On looking into implementation complexity I've come up with simplifications 
> that don't reduce expressive power at all, but massively simplify 
> implementation (and documentation, and testing...) burdens.
> https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Data+Layering+for+base64+-+Simplified

Reply via email to