Re: a question about <forall> element

I stand corrected then, Robert.

However, it does say "should", not "must", so any content element is OK, 
sort of, except reln, which is explicitly depracated. You may have to 
fix the validation grammar then (though it should issue a warning, I 

Still, the original poster appears to have hit upon a serious problem 
here.  I can't think of a single case where insisting on a specific type 
of argument would be OK in all cases.  In this particular case, just 
replace the body, variable x, with a logical constant such as true or 
false, and you have a perfectly sensible mathematical statement that 
should be representable in a straight-forward way without inserting an 
identity function into it somehow.

This reminds me of a problem that I posted a long, long time ago, about 
having interval both as a constructor and as a qualifier element. 
 That's a dangerous syntactic ambiguity: is an apply with an integral 
operator and an interval element a) an operator on functions which 
returns the integral of an argument function over that interval, or b) 
the indefinite integral of an interval-valued function?  

 -- Andreas

>>The misunderstanding may be about <forall/> being required to be used 
>>within the context of an apply element.  That refers to the apply 
>>element within which the forall element is embedded, however, and 
>>therefore there is no problem if there is no apply element as a sibling 
>>of the forall element.
>That may be the sensible interpretation, but it isn't how the spec is
>written.  From 4.3.17:
>  "The forall element represents the universal quantifier of logic. It
>  must be used in conjunction with one or more bound variables, an
>  optional condition element, and an assertion, which should take the
>  form of an apply element. In MathML 1.0, the reln element was also
>  permitted here: this usage is now deprecated."
>And from the validation grammer, C.2.3.18:
>  "Signature 
>    (bvar*,condition?,apply) -> boolean 
>    (bvar*,condition?,(reln)) -> boolean "

Received on Tuesday, 6 May 2003 11:59:05 UTC