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@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