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