On Thu, Nov 5, 2020 at 4:07 PM Steve Lawrence <slawrence@tresys.com> wrote:

I know of uses where fn:count has been used as a way to keep a running
sum via inputValueCalc. For example:

<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element name="array" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="val" type="xs:int" ... />
<xs:element name="sum" type="xs:int"
dfdl:inputValueCalc="{
if (fn:count(../../array) eq 1)
then ../val
else ../../array[fn:count(../../array) - 1]/sum
}" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="total" type="xs:int"
dfdl:inputValueCalc="{ ../array[fn:count(../array)]/sum }" />
</xs:sequence>
</xs:complexType>
</xs:element>

Would something like this no longer be allowed under this proposal?

On 11/5/20 3:42 PM, Mike Beckerle wrote:
> There are 4 functions which operate on the infoset and it is unclear their
> behavior depending on when they are evaluated during parse/unparse.
>
> The 4 functions are fn:count, fn:exists, fn:exactly-one, and fn:empty.
>
> The behavior when unparsing is less problematic, because one could simply
> require the infoset nodes being referenced to be fully-constructed before these
> functions are allowed to evaluate.
>
> However, when parsing the behavior is more subtle, and unparsing may want to be
> made consistent with decisions about behavior for parsing.
>
> Our call minutes about this action item suggest reviewing the known-to-exist and
> known-not-to-exist definitions to see whether these function definitions should
> be defined in terms of that. I have reviewed those sections, and so far I'm not
> sure they will contribute.
>
> The general problem is this, in terms of fn:count(path). The path is to an
> infoset node or an array of occurrences that is currently being parsed. It is
> possible that the status of known-to-exist or not is simply not well known at
> the point the expression is being evaluated.
>
> The answer to fn:count(path) wants to always be the same as if the infoset were
> fully constructed at the time the expression is evaluated. As evaluation may
> occur during parsing, it is just not defined if the evaluation of the expression
> itself determines whether the item itself is known to exist or not.
>
> Ex:
>
> <xs:element name="outerArray" maxOccurs="unbounded">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="innerArray" maxOccurs="unbounded">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="count" type="xs:int" dfdl:inputValueCalc='{
> fn:count(../..) }'/>
> ....
> </xs:sequence>
> </x:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexTYpe>
> </xs:element>
>
> In the above, we see that fn:count has as argument a relative path to the array
> element named "outerArray".
>
> There are a few observations here.
>
> 1) If we define fn:count in this case to actually have anything to do with the
> current number of array elements in outerArray, then we will have tightly
> constrained implementations to a very sequential notion of parsing. The notion
> of "current" state of the array implies an algorithm where the number of current
> occurrences is changing. E.g., we would preclude an implementation that knows
> the length of all outerArray elements from parsing all the children
> simultaneously in parallel, or at minimum make this quite hard to achieve
> because each parallel computation would have to somehow simulate the right
> "current number" of occurrences.
>
> 2) The question arises of fn:count(../..) vs. fn:count(../../../outerArray), vs.
> fn:count(../../../outerArray[i]) where i is the index of the enclosing parent
> outerArray instance that contains this calculation. Arguably, fn:count(../..)
> could be considered equivalent to fn:count(../../../outerArray[i]), both of
> which seem like they should always return '1' since the count of number of
> instances of a single index point, single node, is 1.
>
> 3) Arguably, fn:count(path) could be illegal whenever the path is to an
> enclosing element. We could simply define this usage to be illegal. I cannot
> come up with any reason to actually need this functionality. When parsing we
> could require the path argument to be to pre-existing part of the infoset, and
> when unparsing it would have to be to either pre-existing or later parts of the
> infoset, but specifically not the current infoset elements. If we make this an
> SDE, then this would seem to be the conservative design point which preserves
> our ability to assign a future meaning to this usage, should a need arise.
>
> My recommendation: Expressions evaluated as part of an element parsing or
> unparsing cannot refer to the count or existence of the current element
> occurrence being parsed, nor any enclosing element occurrence, nor any enclosing
> array element.
>
> This would seem to rule out any use of absolute paths in arguments to fn:count,
> because the root element is not (necessarily) known-to-exist until the entire
> parse completes successfully. Yet clearly we want to be able to refer to the
> fn:count of a prior sibling array, and that reference should be able to use
> either a relative or absolute path.
>
> So it's not that the argument path "passes through" a node that may or may not
> exist, but that it ends on one that the existence or not of which doesn't depend
> on the existence or not of the current node.
>
> I'm a bit uncertain of good language to express this constraint on what the path
> argument is allowed to refer to, but the notion is one of a sort of circular
> definition; hence, it's a schema definition error.
>
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense |
> www.owlcyberdefense.com <http://www.owlcyberdefense.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@ogf.org
> https://www.ogf.org/mailman/listinfo/dfdl-wg
>

--
dfdl-wg mailing list
dfdl-wg@ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg