ORA-FS-002-E: Formal Semantics comments, clarification

These are Oracle's Formal Semantics Last Call comments, clarification.

By "clarification" we mean suggestions to make the text clearer, plus 
some calrification questions.

Each comment has a header, with a number, the section, section title, an 
internal-to-Oracle comment number, and a 1-line summary.

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

C1. SECTION 6.1.1, The arithmetic operator pseudo-functions

433: Consider union types
clarification

Consider a '+' operation :  $x + $y
Let's say $x has formal semantic type during static analysis of xs:date,
and $y has formal semantic type during static analysis of 
(xdt:yearMonthDuration |xdt:dayTimeDuration).

Then the '+' operator may be mapped to op:add-yearMonthDuration OR 
op:add-dayTimeDuration, depending on $y's type.
So the static type analysis should be normalized into the following 
xquery expression:
if ($y is xdt:yearMonthDuration)  
  then op:add-yearMonthDuration($x, $y)  
  else op:add-dayTimeDuration($x, $y).

Whenever there is a union type, all type combinations should be checked.

Suggest: FS should make it clear how union types are dealt with by the 
pseudo-functions.

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

C2. SECTION 3.4.4, Sequence Type Matching

459: normalization of processing-instructon()
clarification

Clarification: 3.4.4 should make a reference to 7.2.3.1.2 for 
processing-instruction
to explain why the normalization of
processing-instruction(string) == processing-instruction ?

7.2.3.1.2 seems to say that the target name of the PI is not preserved 
to the FS type.
Why not ?


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

C3. SECTION 3.4.1, Predefined Types

463: xs:anyType definition
clarification

"define type xs:anyType restricts xs:anyType { ... }"

Why is xs:anyType a restriction of xs:anyType?

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

C4. SECTION 6.2.6, The fn:min, fn:max... functions

440: There is no formal rule to specify how the common target type T is 
computed
clarification

The 3rd premise of the 1st inference rule states T is computed as:
Type1 can be promoted to T.  
And T can be one of xs:decimal, xs:float, xs:double, 
xdt:dayTimeDuration, xdt:yearMonthDuration for fn:max.

But it does NOT define how common T is selected in the first place.

For example, consider:
fn:max(1, 3.4)
In this case, the first item is xs:integer and the second is xs:decimal.
Then should T be xs:decimal or can T be xs:float or xs:double ?
Presumably the intention is to let T be xs:decimal, that is, the
smallest common type. But the spec should make this clear.

This definition can also be used in 'order by spec'.

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

Received on Friday, 16 April 2004 00:00:53 UTC