<br><font size=2 face="sans-serif">Attended: Mike Beckerle, Geoff Judd,
Alan Powell, Simon Parker</font>
<br>
<br><font size=2 face="sans-serif">Continued review of Simon Parker's comments
on draft 019. Resolved a few. General principle is to be conservative,
things that we can liberalize later if needed we will choose to be more
restrictive about in v1.0.</font>
<br>
<br><font size=2 face="sans-serif">sp25 - hidden. Keep as just elements.
(Conservative)</font>
<br>
<br><font size=2 face="sans-serif">sp28 - leave out multivalued for now.
(Conservative)</font>
<br>
<br><font size=2 face="sans-serif">sp32 - change to &nbsp;just refer to
XPath 2.0 definition of effective boolean value.</font>
<br>
<br><font size=2 face="sans-serif">sp33 - as early as possible. (Conservative)
, i.e., when scope where property is bound is entered is when expressions
are evaluated.</font>
<br>
<br><font size=2 face="sans-serif">sp35&amp; sp36 - remove this sectino
(it's an artifact of layering that was removed from v1.0)</font>
<br>
<br><font size=2 face="sans-serif">&nbsp;Action Item: Alan Powell and Goeff
Judd - &nbsp;regexp - revisit swift need for regexp in IBM mrm parser.
Contrast with TX speculative approach. Report back.</font>
<br>
<br><font size=2 face="sans-serif">Additional point - certain properties
may be regular expressions (escape syntax TBD) - we concluded that this
really is needed. Case sensitive and insensitive, various line endings
tolerated. </font>
<br>
<br><font size=2 face="sans-serif">sp37 - conservative choice: require
{} around expressions in all contexts.</font>
<br>