[DFDL-WG] Resolving points of Uncertainty (potentially uncertainty)

[Alan Powell]

Minutes of Oct 14th

5. Resolving points of uncertainty and parsing rules 
Alan & Steve H spent some time discussing the uncertainty document and 
Alan has sent out a revision for review.  Comments welcome, especially on 
the listed rules for resolving uncertainty.

Steve H wants to ensure that the rules for resolving uncertainty do not 
preclude the use of 'on-demand' parsing as this is a valuable performance 
and memory technique for implementations. Steve thinks that the current 
rules should be ok. And there will always be some formats to which 
on-demand parsing can't be applied well.

A problem was spotted with uncertainty and arrays. If an element has 
minOccurs not equal to maxOccurs, but greater than zero (say x), then the 
point of uncertainty does not actually start until index x+1.  What does 
it mean to place a discriminator on that element (or one of its children 
if complex) ?  The rules as worded mean that for indices less than x+1, 
the discriminator might actually be used to resolve a higher point of 
uncertainty. Which is clearly wrong. 

Mike agreed that the full solution to this is part of existing action 033 
which is looking at the need to scope indicators on discriminators.  All 
agreed that scope indicators should be avoided if at all possible. 

A proposal was put forward for handling this specific array scenario.  As 
well as states 'certain' and 'uncertain' add the concept of a 'possibly 
uncertain' state (better name welcome). This state is entered for the 
array element described above when processing indices 1 through x. Any 
discriminator evaluated in this state can result in false and cause 
backtracking, but if it evaluates to true it does not resolve anything. 
That can only happen in the 'uncertain' state.

---------------------------------------------------------------------------------------------------------------------------------------------

I am wary of the 'potentially uncertain' state as I think it adds 
unnecessary complication.
I wasn't on the call but I assume it was introduced as a way of tying the 
discriminator to resolving whether the element exists and not some 
previous uncertainty. 

An alternative might be to consider an array as two points of uncertainty. 
On point is for the array and the other, which is nested inside the first, 
 for the element. We can then have the rule that the discriminator 
resolves the element uncertainty only which always exists so doesn't need 
to be 'potential'.
The array uncertainty is resolved when minOccurs have been found.

Alan Powell

 MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
 Notes Id: Alan Powell/UK/IBM     email: alan_powell at uk.ibm.com 
 Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898






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/20091028/864ca95f/attachment.html