1 / 62

XQuery 1.0 Formal Semantics

Formal Semantics. XQuery 1.0 Formal Semantics. Presented by:. Michael Ryabtzev Kravtsov Valentin. Introduction to the Formal Semantics. The goal of the formal semantics is to complement the specification , by defining the meaning of expressions with mathematical rigor.

kedma
Download Presentation

XQuery 1.0 Formal Semantics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Semantics XQuery 1.0 Formal Semantics Presented by: Michael Ryabtzev Kravtsov Valentin

  2. Introduction to the Formal Semantics • The goal of the formal semantics is to complement the specification , by defining the meaning of expressions with mathematical rigor. • Clarifies the intended meaning • Ensures that no corner cases are left out • Provides a reference for implementation

  3. XQuery Processing Model

  4. Formal Semantics defines static semantics, dynamic semantics and normalization rules: • The static semanticsdescribes how the output type is inferred from the core operator tree and the input type. • The dynamic semantics describes how the output instance produced by using the accessors and constructors defined in the XQuery Data Model. • Thenormalization rules transform full XQuery into small core language, which is easier to define, implement and optimize.

  5. Dynamic Semantics: Formal notation: Expr Value This is read, “Evaluation of expression Expryields value Value” We call this an evaluation judgment. Definition of expressions: Definition of values: Expr ::= Value | Expr < Expr | Expr + Expr | if(Expr) thenExpr else Expr Value ::== Boolean | Integer Boolean ::== fn:true() | fn:false() Integer ::== 0 | 1 | -1 | 2 | …

  6. Dynamic Semantics: First 5 rules of Evaluations: _______________ Value  Value (VALUE) Hypotheses Expr0  Integer0 Expr1 Integer1_________ Expr0 < Expr1 Integer0 < Integer1 Conclusion (LT) Expr0  Integer0 Expr1 Integer1________ Expr0 + Expr1 Integer0 + Integer1 (SUM)

  7. Dynamic Semantics: Evaluations: Expr0 fn:true() Expr1Value_________ If (Expr0) then Expr1else Expr2  Value (IF-TRUE) Expr0 fn:false() Expr2 Value_________ If (Expr0) then Expr1else Expr2  Value (IF-FALSE)

  8. Dynamic Semantics: Example of proof tree for expression: (VALUE) 1 1 (VALUE) 2 2 (LT) 1 < 2 fn:true() (VALUE) 3 3 (VALUE) 4 4 (SUM) 3 + 4 7 (IF-TRUE) if (1 < 2) then 3 + 4 else 5 + 6 7 Note that Expr2 = 5 + 6 did not appear in the hypotheses, which formalizes the intuition that the else branch is not evaluated when the condition is true.

  9. Environments: Environment – a judgment relating expression to a value. Formal notation: dynEnv |- Expr Value This is read, “In environment dynEnv, the evaluation of expression Expr yields the value Value”. Notations that manipulate environments:

  10. Environments: Examples of environments: dynEnv0 = Ø dynEnv1 = dynEnv0 + varValue(x 1) = varValue(x 1) dynEnv2 = dynEnv1 + varValue(y  2) = varValue(x 1, y  2) dynEnv3 = dynEnv2 + varValue(x 3) = varValue(x 3, y 2) dynEnv2.varValue(x) = 1 dom(dynEnv0.varValue) = Ø dom(dynEnv3.varValue) = { x , y } Note that binding a variable in the environment overrides any previous binding for the same variable.

  11. Environments: We can now formalize variables and let expressions: Expr ::= Value | Expr < Expr | Expr + Expr | if(Expr) thenExpr else Expr | $Var | let $Var := Expr return Expr

  12. Environments: The 5 rules we gave before need to be revised to mention the environment. Example for revision of 2 first rules: _______________ dynEnv |-Value  Value dynEnv |- Env Expr0  Integer0 dynEnv |- Expr1 Integer1_________ dynEnv |- Expr0 < Expr1 Integer0 < Integer1

  13. Environments: We also need to add two new rules: dynEnv.varValue(Var) = Value______ dynEnv |- $Var Value dynEnv |- Expr0  Value0 dynEnv + varValue(Var  Value0) |-Expr1  Value1 dynEnv |-let $Var := Expr0return Expr1 Value1 Note that evaluation of Expr1 is preformed after assigning Value0 to Var.

  14. Matching Values and Types: Lets extend our grammar to represent relationship between values and types: Expr ::= Value | Expr < Expr | Expr + Expr | if(Expr) thenExpr else Expr | $Var | let $Var := Expr return Expr | let $Var as Type := Expr return Expr For now we use only two types: Type ::= xs:boolean | xs:integer

  15. Matching Values and Types: Matching judgment: Value matchesType This is read, “Value Value matches the type Type”. The inference rules for literal expressions: _____________________ Integer matches xs:integer (INT-MATCH) ______________________ Booleanmatches xs:boolean (BOOL-MATCH)

  16. Matching Values and Types: dynEnv |-Expr0  Value0 Value0matches Type dynEnv + varValue(Var  Value0) |-Expr1  Value1 dynEnv |-let $Var as Type := Expr0return Expr1 Value1 The first and the third hypotheses are the same as those in the rule for let without type declarations. The second hypothesis asserts that Value0 matches the declared type.

  17. Errors: Error judgment: dynEnv |-Expr raisesError This is read, “In the environment dynEnv the evaluation of expression Expr raises error Error”. We classify errors as either type errors or dynamic errors. Error ::= typeErr | dynErr

  18. Errors: Lets extend our grammar to illustrate the semantics of errors: Expr ::= Value | Expr < Expr | Expr + Expr | if(Expr) thenExpr else Expr | $Var | let $Var := Expr return Expr | let $Var as Type := Expr return Expr | Expr idiv Expr

  19. Errors: The evaluation rule for division is similar to that for addition: dynEnv |- Expr0 Value0 dynEnv |- Expr1 Value1 Value1 0____________ dynEnv |-Expr0idiv Expr1 Value0idiv Value1 (IDIV) We now add rules that indicate when errors should be raised: dynEnv |- Expr1 0____________ dynEnv |-Expr0idiv Expr1raises dynErr (IDIV-ERR) Note that the rule does not require evaluation of the dividend in Expr0to discover such an error.

  20. Errors: The following rules show how type errors may be raised during evaluation of arithmetic and comparison: dynEnv |- Expr0 Value0 not(Value0matches xs:integer) ____ dynEnv |-Expr0< Expr1 raises typeErr (LT-LEFT-TYPE-ERR) dynEnv |- Expr1 Value1 not(Value1matches xs:integer) ____ dynEnv |-Expr0< Expr1 raises typeErr (LT-RIGHT-TYPE-ERR) The rules for sum, division operators and if expression are omitted but similar.

  21. Errors: The let expression with a type declaration raises an error if the value is not of the declared type: (LEFT-TYPE-ERR) dynEnv |- Expr0 Value0 not(Value0matchesType) ____ dynEnv |-let $Var as Type := Expr0return Expr1raises typeErr

  22. Errors: The following rules illustrate how an error is propagated from the sub-expression in which it occurs to the containing expression: dynEnv |- Expr0raisesError_____ dynEnv |-Expr0 < Expr1raisesError dynEnv |- Expr1raisesError_____ dynEnv |-Expr0 < Expr1raisesError

  23. Errors: In let expression, an error is propagated if it arises in the first or second expression: dynEnv |- Expr0raisesError_____ dynEnv |-let $Var as Type := Expr0return Expr1raisesError dynEnv |- Expr0Value0 dynEnv + varValue(Var  Value0) |- Expr1raisesError___ dynEnv |- let $Var as Type := Expr0return Expr1raisesError Note that we bind the variable to it’s value before checking whether second expression raises an error.

  24. Errors: Here is example of evaluation that raises an error: _______________________________(VALUE) dynEnv0 |- 0  0 (VAR) dynEnv1 |- $x  0 (IDIV-ERR) dynEnv1 |- 1 idiv 0 raises dynErr (SUM-RIGHT-ERR) dynEnv1 |- $x + (1 idiv $x) raises dynErr (LET) dynEnv0 |- let $x := 0 return $x + (1 idiv $x) raises dynErr where dynEnv0 = Ø, dynEnv1 = varValue(x  0).

  25. Static Semantics: Formal notation: statEnv |- Expr Type This is read, “In environment statEnv, expressionExprhas type Type” We call this a typing judgment.

  26. Static Semantics: Here is the XQuery grammar that we have built so far: Value ::= Boolean | Integer Expr ::= Value | Expr < Expr | Expr + Expr | if(Expr) thenExpr else Expr | $Var | let $Var := Expr return Expr | let $Var as Type := Expr return Expr | Expr idiv Expr Type ::= xs:boolean | xs:integer

  27. Static Semantics: Examples of static rules: statEnv |- Expr0:xs:integer statEnv |- Expr1 :xs:integer___ statEnv |- Expr0< Expr1 :xs:boolean (LT-STATIC) statEnv |- Expr0:xs:boolean statEnv |- Expr1 : Type statEnv |- Expr2 : Type________ statEnv |- if (Expr0) then Expr1 elseExpr2:Type (IF-STATIC) statEnv |- Expr0 : Type0 statEnv + varType(Var:Type0) |- Expr1 : Type1___ statEnv |- let $Var as Type0:= Expr0 returnExpr1:Type1 (LET-DECL-STATIC)

  28. Static Semantics: Recall the two dynamic rules for let: dynEnv |-Expr0  Value0 Value0matches Type dynEnv + varValue(Var  Value0) |-Expr1  Value1 dynEnv |-let $Var as Type := Expr0return Expr1 Value1 dynEnv |- Expr0 Value0 not(Value0matchesType) ____ dynEnv |- let $Var as Type := Expr0return Expr1raises typeErr Note that an important consequence of static analysis is that we do not need to check for type errors at evaluation time  matches judgment in the first rule and the entire second rule are redundant when static typing is in effect.

  29. Type Soundness: Lets define the relationship the dynamic environment and corresponding static environment dynEnvmatchesstatEnv If dom(dynEnv.varValue) = dom(statEnv.varType) And for every x in that domain, dynEnv.varValue(x) matches statEnv.varType(x)

  30. Type Soundness: Properties of static type checking Theorem: Type soundness for values if dynEnv matches statEnv dynEnv |- Expr  Value statEnv |- Expr : Type then Value matches Type Theorem: Type Soundness for Errors if dynEnv matches statEnv dynEnv |- Expr raises Error statEnv |- Expr : Type then Error  typeErr

  31. Normalization: Formal notation: [FullExpr]Expr == Expr The Expr subscript indicates that full XQuery expression can be normalized by the rule. For example: [let $Var as Type := Expr0 where Expr1 return Expr2]Expr == let $Var as Type := [Expr0]Expr return if ([Expr1]Expr) then [Expr2] else ()

  32. Values and Typing: We start with the formal notation for values: Value ::= () | Item (,Item)* Item ::= AtomicValue | NodeValue AtomicValue ::= xs:integer(String) | xs:boolean(String) | xs:string(String) | xs:date(String) NodeValue ::= element ElementName TypeAnnotation? {Value} | text {String} ElementName ::= QName TypeAnnotation ::= of type TypeName TypeName ::= QName

  33. Values and Typing: <user> <name><first>Mary</first><last>Doe</last><name> <rating>A</rating> </user> element user of type User { element name of type Name { element first of type xs:string { “Mary” } , element last of type xs:string { “Doe” } } , element rating of type xs:string { “A” } }

  34. Values and Typing: The formal notation for types: At the top level one can define elements and types Definition ::= define element ElementName TypeAnnotation | define type TypeName TypeDerivation TypeAnnotation ::= of type TypeName TypeDerivation ::= restrics AtomicTypeName | restrics TypeName {Type} | {Type}

  35. Values and Typing: Type ::= none() | empty() | ItemType | Type , Type | Type | Type | Type Occurrence Occurrence ::= ? | + | * SimpleType ::= AtomicType | SimpleType | SimpleType | SimpleType Occurrence

  36. Values and Typing: ItemType ::= NodeType | AtomicType NodeType ::= ElementType | text() AtomicType ::= AtomicTypeName AtomicTypeName ::= xs:string | xs:integer | xs:date | xs:boolean ElementType ::= element((ElementName (,TypeName)?)?)

  37. Values and Typing: Example: <xs:element name=“article" type=“Article"/> <xs:complexType name=“Article"> <xs:sequence> <xs:element name=“name" type=“xs:string"/> <xs:element name=“reserve_price" type=“PriceList" minOccurs="0“ maxOccurs=“unbounded”/> </xs:sequence> </xs:complexType> <xs:simpleType name=“PriceList”> <xs:list itemType = “xs:decimal” /> </xs:simpleType> define element article of type Article define type Article{ element (name, xs:string), element (reserve_price,PriceList) * } define type PriceList restricts xs:anySimpleType {xs:decimal * }

  38. Matching and Subtyping: • Now lets define matching to relate complex XML values with complex types. Example: <reserve_price>10.00 20.00 30.00</reserve_price> Before validation, this element is represented by the following untyped XML value: element reserve_price { text { “ 10.00 20.00 30.00 “ } } After validation, this element is represented by the following typed XML value: element reserve_price of type PriceList { 10.0 20.0 30.0 } element reserve_price of type PriceList {10.0 20.00 30.00} matches element(reserve_price)

  39. Matching and Subtyping: Rule for matching elements against element types: statEnv |- ElementType yields element (ElementName1, TypeName1) statEnv |- ElementName substitutes for ElementName1 statEnv |- TypeName derives from TypeName1 statEnv |- Value matches TypeName_____________ statEnv |- element ElementName of type TypeName {Value} matchesElementType

  40. Matching and Subtyping: Yields judgment: ElementTypeyields element (ElementName,ElementType) statEnv |- define element ElementName of type ElementType statEnv |- element(ElementName) yields element(ElementName,ElementType) Example: element(article) yields element(article,Article) ____________________________________________________ statEnv |- element(ElementName,ElementType) yields element(ElementName,ElementType) Example: element(reserve_price,PriceList) yields element(reserve_price,PriceList)

  41. Matching and Subtyping: ____________________________________________________ statEnv |-element(*,ElementType) yields element(*,ElementType) Example: element(*,PriceList) yields element(*,PriceList) ____________________________________________________ statEnv |-element() yields element(*,xs:anyType) Example: element() yields element(*,xs:anyType)

  42. Matching and Subtyping: Substitution judgment: ElementName1substitutes for ElementName2 ____________________________________________________ statEnv |-ElementName substitutes for ElementName ____________________________________________________ statEnv |-ElementName substitutes for *

  43. Matching and Subtyping: Derives judgment: TypeName1derives from TypeName2 define type TypeName restricts TypeName1 TypeName derives from TypeName1 define type TypeName restricts TypeName1 {Type} TypeName derives from TypeName1 ___________________________________________ TypeName derives from TypeName TypeName1derives from TypeName2 TypeName2derives from TypeName3 TypeName1derives from TypeName3

  44. Matching and Subtyping: Matches judgment: Valuematches Type __________________________________ ()matches empty() AtomicTypeName derives from xs:integer Integer matches AtomicTypeName Value1matches Type1 Value2matches Type2 Value1, Value2match Type1, Type2

  45. Matching and Subtyping: Value matches Type1 Value matches Type1 | Type2 Value matches Type2 Value matches Type1 | Type2 Value matches empty() |Type Value matches Type? Value matches Type ,Type* Value matches Type+ Value matches Type+ ? Value matches Type*

  46. Matching and Subtyping: Subtyping judgment: Type1subtype Type2 holds if every value that matches the first type also matches the second. Example: element (article)+ subtype element (article)* element (*,NewUser) subtype element (*,User) Subtyping is defined by logical equivalence: Type1subtype Type2 if and only if Value matches Type1 implies Value matches Type2 Example: (element(), text())* , element() , text() (element(), text())+ element(), text() , (element() , text())*

  47. FLWOR Expressions: FLWOR Expressions – the “workhorse” of XQuery. Example of XQuery FLWOR Expression: for $i in $I, $j in $J let $k := $i + $j where $k >= 5 return ( $i , $j )

  48. FLWOR Expressions: Grammar for the FLWOR Expressions Expr := … previous expressions… | FLWRExpr FLWRExpr := Clause + return Expr Clause := ForExpr | LetExpr | WhereExpr ForExpr := for ForBinding (,ForBinding)* LetExpr := let LetBinding (,LetBinding)* WhereExpr := where Expr ForBinding := $Var TypeDeclaration? PositionalVar? in Expr LetBinding := $Var TypeDeclaration? := Expr TypeDeclaration := as SequenceType PositionalVar := at $Var SequenceType := ItemType Occurence

  49. FLWOR Expressions - Normalization: Normalization – it is easier to define the static and dynamic semantics of an expressions if it is small and doesn’t do too much. for $i in $I, $j in $J let $k := $i + $j where $k >= 5 return ( $i , $j ) Normalization for $i in $I return for $j in $J return let $k := $i + $j return if ($k >= 5) then return ( $i , $j ) else ()

  50. FLWOR Expressions - Normalization: [Clause1 ... Clausen return Expr]Expr == [Clause1 return ... [Clausen return Expr]Expr]Expr’ (n>1) [for ForBinding1 ... ForBindingn return Expr]Expr == [for ForBinding1 ... [ForBindingn return Expr]Expr]Expr’ (n>1) [let LetBinding1 ... LetBindingn return Expr]Expr == [let LetBinding1 ... [LetBindingn return Expr]Expr]Expr’ (n>1)

More Related