[DFDL-WG] test case length_delimited_12_03

[Mike Beckerle]

This is a very good point. With no delimiters specified the lenthKind
delimited effectively becomes terminated by end of data.
 On Jun 27, 2012 12:59 PM, "Steve Hanson" <smh at uk.ibm.com> wrote:

> After discussion by the DFDL WG, it was noted that applying a default
> lengthKind of 'delimited' to all the elements in a DFDL model for CSV would
> cause the root element to be using 'delimited' without any delimiters in
> scope.  Further spec section 12.3.2 specifically allows for end-of-data
> being a valid reason for successfully ending a delimited scan. Therefore it
> is not correct for 'delimited' and no delimiters to give rise to an SDE.
>
> Regards
>
> Steve Hanson
> Architect, Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        Steve Hanson/UK/IBM
> To:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> Cc:        dfdl-wg at ogf.org, dfdl-wg-bounces at ogf.org
> Date:        21/06/2012 15:49
> Subject:        Re: [DFDL-WG] test case length_delimited_12_03
> ------------------------------
>
>
> Hi Mike
>
> I think the test case can be explained by the fact that IBM DFDL does not
> yet support dfdl:lenghKind = 'endOfParent', hence any test case would try
> to use 'delimited'.
>
> I don't have an issue with saying that encountering dfdl:lengthKind
> 'delimited' while parsing  but having no delimiters in scope, is an SDE.
> It's almost certainly an indication the model is wrong.
>
> Regards
>
> Steve Hanson
> Architect, Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        dfdl-wg at ogf.org
> Date:        21/06/2012 13:20
> Subject:        [DFDL-WG] test case length_delimited_12_03
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
>
> IBM published a set of test cases for DFDL. One of them is
> length_delimited_12_03.
>
> I want to discuss whether this is in fact the behavior we want for DFDL.
>
> In this example, there is data "abcde", and the default format is
> lengthKind="delimited", but no delimiters are defined anywhere.
>
> <!--  parent with specified length -->
>
>        <xs:element name=*"myStringSeq2"* dfdl:lengthKind=*"explicit"*
> dfdl:length=*"5"*>
>
>               <xs:complexType>
>
>                      <xs:sequence dfdl:initiatedContent=*"no"*
> dfdl:separatorPosition=*"infix"*
>
>                            dfdl:sequenceKind=*"ordered"* dfdl:separator=*
> ""* >
>
>                            <xs:element name=*"Test1"* type=*"xs:string"*>
>
>                            </xs:element>
>
>
>
>
>
>                      </xs:sequence>
>
>               </xs:complexType>
>
>
>
>        </xs:element>
>
>
> The only way for this to parse is for the inner element Test1 to be
> delimited by the end-of-data coming from the explicit surrounding box
> created by the myStringSeq2.
>
> I thought this should be a SDE because no delimiter is defined anywhere. I
> see that it can work, if we adopt a policy that delimited, but with no
> delimiters, means delimited by end-of-available-data.
>
> But, I thought that is what lengthKind="endOfData" is for.
>
> Can anyone comment as to why the lengthKind="delimited" but with no
> delimiter strings defined should NOT be an SDE?
> --
>  dfdl-wg mailing list
>  dfdl-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> --
>  dfdl-wg mailing list
>  dfdl-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120627/181d972b/attachment-0001.html>