[DFDL-WG] recent puzzlers on fn:count and fn:exists

Mike Beckerle mbeckerle.dfdl at gmail.com
Wed Oct 9 10:21:11 EDT 2019


dfdl:occursIndex returns the current index of the innermost array context.

fn:count only returns the same thing if you happen to be calling it from
within the array element itself, referring to the array itself, and only if
we define it to do so. Otherwise it is returning the size of some other
array.

Arguably, the fn:count of the array, at the time one is parsing it, isn't
well defined. In particular, if you are speculatively parsing the array, is
the currently speculated element in the count or not? It could fail
subsequently, and cause backtracking.


Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>



On Tue, Oct 8, 2019 at 12:26 PM Steve Hanson <smh at uk.ibm.com> wrote:

> I think we will have to go back to the XPath function spec and see what
> that says.  https://www.w3.org/TR/xpath-functions-31/#func-count.
>
> If fn:count(.) returns the same as dfdl:occursIndex() then what is the
> point of the latter? If I recall it was added to allow a reference from one
> array to the same occurrence in another array, eg,
>
>   dfdl:length="{/doc/lengths[dfdl:occursIndex(.)]}"
>
> Regards
>
> Steve Hanson
>
> IBM Hybrid Integration, Hursley, UK
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> *smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
> mob:+44-7717-378890
> Note: I work Tuesday to Friday
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        DFDL-WG <dfdl-wg at ogf.org>
> Date:        08/10/2019 17:06
> Subject:        [DFDL-WG] recent puzzlers on fn:count and fn:exists
> Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>
> ------------------------------
>
>
>
>
> These questions came up recently from daffodil users. I know what Daffodil
> will return here, but the spec is not clear to me as to whether that's the
> right answer or is even defined.
>
> Can an array count itself? Like this:
>
> <xs:element name="name" type="xs:string" maxOccurs="unbounded">
>     <xs:annotation>
>         <xs:appinfo source="*http://www.ogf.org/dfdl/*
> <http://www.ogf.org/dfdl/>">
>             <dfdl:discriminator test="{ fn:count(.) le 5 }" />
>         </xs:appinfo>
>     </xs:annotation>
> </xs:element>
>
> The above can be reformulated by calling instead of fn:count,
> dfdl:occursIndex(), and that's definitely well defined in this case. But
> what does fn:count return in this case? Daffodil will return the same value
> as the occursIndex, because it will have speculatively attached the array
> element to the infoset at the time the fn:count function is being
> evaluated. But I don't know if that is the right answer or if we should
> simply say that fn:count is not defined in this case.
>
> Similarly, does an array element exist when it is being parsed?
>
> <xs:element name="name" type="xs:string" maxOccurs="unbounded">
>     <xs:annotation>
>         <xs:appinfo source="*http://www.ogf.org/dfdl/*
> <http://www.ogf.org/dfdl/>">
>             <dfdl:discriminator test="{ fn:exists(.) }" />
>         </xs:appinfo>
>     </xs:annotation>
> </xs:element>
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
> *www.tresys.com* <http://www.tresys.com>
> Please note: Contributions to the DFDL Workgroup's email discussions are
> subject to the *OGF Intellectual Property Policy*
> <http://www.ogf.org/About/abt_policies.php>
> --
>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20191009/f2f2fd39/attachment.html>


More information about the dfdl-wg mailing list