If the input is a (possibly empty) sequence of nodes, fs:node-sequence
simply returns that sequence. Otherwise, it raises a type
error.
The static type of a call to fs:node-sequence
is
that of its argument, as long as that type is a subtype of
node()*
.
| statEnv |- Type <: [node()*]sequencetype |
|
|
statEnv |- (FS-URI ,"node-sequence ")(Type)
: Type |
item-at
functionfs:item-at
($sourceSeq
as
item()*
,
$loc
as
xs:double
) as
item()?
The fs:item-at
function returns the item at a specified position in a
sequence.
If $loc
is numeric-equal to the position of some
item in $sourceSeq
, that item is returned. (This
implies that $sourceSeq
is non-empty, and
$loc
is numeric-equal to an integer between 1 and
n
inclusive, where n
is the number of
items in $sourceSeq
.)
Otherwise, the empty sequence is returned.
The function is roughly equivalent to the following user-defined function.
declare function fs:item-at( $sourceSeq as item()*, $loc as xs:double) as item()? { if ($loc mod 1 eq 0) then fn:subsequence($sourceSeq,$loc,1) else () };
The static typing rules for invocations of fs:item-at
depend on the
syntactic form of the second argument. If it is the IntegerLiteral
1, then we can be relatively precise about the resulting type.
|
||||
|
|
||||
|
Otherwise, the following less precise rule is used.
|
|||
|
|
|||
|
(Since invocations of fs:item-at
arise only as
the result of particular normalization rules, Expr2 in the
above rule must be either $fs:last
,
$fs:position
, or a NumericLiteral. Thus, there is no
need to check its type.)
Introduction
This section gives special normalization and static typing rules for functions in [XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)] for which the standard normalization or static typing rules are not appropriate. All functions that are not mentioned behave as described in Section [4.1.5 Function Calls]. When given, the static typing rules in this section always give more precise type information than the generic rule based on the function's signature.
fn:last
context functionAs explained in [3.1.2 Dynamic
Context], the fn:last()
context function is
modeled using the Formal Semantics variable $
fs:last
.
For that function the following static typing and dynamic
evaluation rules apply.
fn:position
context functionAs explained in [3.1.2 Dynamic
Context], the fn:position()
context function
is modeled using the Formal Semantics variable $
fs:position
.
For that function the following static typing and dynamic
evaluation rules apply.
fn:abs
, fn:ceiling
,
fn:floor
, fn:round
, and
fn:round-half-to-even
functionsNotation
The auxiliary judgment has base atomic type is used in the next subsection and also in [7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions].
To a first approximation, this judgment holds when AtomicTypeName1
is (or is derived from) primitive atomic type AtomicTypeName2.
However, for the purpose of typing the functions that use this
judgment, there are three non-primitive atomic types that are
treated similarly to primitive types: xs:integer
(derived from xs:decimal
), and xs:yearMonthDuration
and
xs:dayTimeDuration
(derived from xs:duration
).
If AtomicTypeName1
is (or is a subtype of) any primitive atomic type other than
xs:decimal
or xs:duration
, then that type
is its base atomic type.
|
||||
|
|
||||
|
Similarly for xs:integer
, xs:yearMonthDuration
, and
xs:dayTimeDuration
.
|
|||
|
|
|||
|
For xs:decimal
, we exclude xs:integer
and its subtypes:
|
|||
|
|
|||
|
And finally, for xs:duration
, we exclude xs:yearMonthDuration
and
xs:dayTimeDuration
,
and their subtypes.
|
||||
|
|
||||
|
Note that, in the declarations for the built-in functions
fn:abs
, fn:ceiling
,
fn:floor
, fn:round
, and
fn:round-half-to-even
, the (first) parameter is
declared with type "numeric?
". Thus, for a call to one
of these functions, the normalization rules of [4.1.5 Function Calls] will have
wrapped the argument in calls to fn:data
() and
fs:convert-simple-operand
()
(with a 'prototypical value' of type xs:double
). Thus,
static analysis of the call is guaranteed that the argument type is
a subtype of xs:anyAtomicType
*, with no
occurrences of xs:untypedAtomic
.
In the static typing rule for these functions, we check that the argument type is numeric, extract its prime type (which must be a choice of atomic types), find the base atomic type for each, and then form the choice of those results.
|
||||||||
|
|
||||||||
|
The fn:round-half-to-even
function also has a
two-parameter version. Its static type-checking can be reduced to
that of the one-parameter version.
fn:boolean
and fn:not
functionsThe fn:boolean
function as described in the
[XQuery 1.0 and XPath 2.0 Functions and
Operators (Second Edition)] document takes an empty sequence, a
sequence whose first item is a node, or a singleton value of type
xs:boolean
, xs:string
,
xs:anyURI
, xs:untypedAtomic
or some
numeric type. All other values are illegal. The static typing of
fn:boolean
reflects these restrictions, but further
constrains "a sequence whose first item is a node" to "a sequence
of nodes".
The fn:not
function has an implicit call to
fn:boolean
, and raises type errors for the same cases,
so its static typing is the same as fn:boolean
.
|
|||
|
|
|||
statEnv
|- expanded-QName(Type) : xs:boolean |
fn:collection
and fn:doc
functionsIntroduction
The static typing rules for fn:collection
and
fn:doc
depend on the syntactic form of their input
expression. As a result, the corresponding static typing rules must
be written directly over the input expression, unlike the other
functions in this section.
The fn:collection
function as described in the
[XQuery 1.0 and XPath 2.0 Functions and
Operators (Second Edition)] document, takes a string-valued
expression, which denotes a URI, and returns a value.
If the fn:collection
function has no parameter, the
result type is given by the implementation for the default sequence
if it exists.
|
|||
|
|
|||
| statEnv |- QName() : Type |
If the argument to fn:collection
is a
URILiteral expression which is defined in statEnv.collectionType, then the
result type is the type corresponding to the URILiteral in
statEnv.collectionType.
|
|||
|
|
|||
| statEnv |- QName(URILiteral) : Type |
Otherwise, if the argument is a URI literal but is not defined in statEnv.collectionType, or if it is not a URI literal, then we don't know anything about the URI and the static type is a collection of nodes.
|
|||
|
|
|||
| statEnv |- QName(URILiteral) : (element * | attribute * | processing-instruction * | text | comment | document ) * |
|
|||
|
|
|||
| statEnv |- QName(Expr) : (element * | attribute * | processing-instruction * | text | comment | document ) * |
The fn:doc
function has similar static typing
rules, but, in addition, the static type must be a document
node.
|
||||
|
|
||||
| statEnv |- QName(URILiteral) : Type |
Otherwise, if the argument is a URI literal not defined in the domain of statEnv.docType or if it is not a URI literal, then we don't know anything about the URI, and the static type is document.
|
|||
|
|
|||
| statEnv |- QName(URILiteral) : document? |
|
|||
|
|
|||
| statEnv |- QName(Expr) : document? |
fn:data
functionIntroduction
The fn:data
function converts a sequence of items
to a sequence of atomic values.
Notation
Inferring the type for the fn:data
function is done by applying the data on auxiliary judgment, using the same
approach as for the XPath steps.
The general rule for fn:data
is to apply the filter
data on to the prime
type of its argument type, then apply the quantifier to the
result:
When applied to none, data on yields none.
When applied to empty, data on yields empty.
When applied to the union of two types, data on is applied to each of the two types. The resulting type is computed using prime and quantifier, which are defined in [8.4 Judgments for FLWOR and other expressions on sequences]. This rule is necessary because data on may return a sequence of atomic types.
|
|||
|
|
|||
| statEnv |- data on (Type1|Type2) : prime(Type1'|Type2') · quantifier(Type1'|Type2') |
When applied to an atomic type, data on simply returns the atomic type:
When applied to comment or processing instruction node types,
data on returns
xs:string
When applied to text or document node types, data on returns xs:untypedAtomic
When applied to element node types with type
annotationXQ xs:untyped
, the data on filter returns
xs:untypedAtomic
.
|
||
|
|
||
statEnv |- data on ElementType : xs:untypedAtomic |
When applied to an attribute node type, the data on filter returns the attribute's simple type.
|
|||
|
|
|||
| statEnv |- data on AttributeType : Type |
When applied to an element type whose type annotationXQ denotes a simple type or a complex type of simple content, data on returns the element's simple type.
|
||||
|
|
||||
| statEnv |- data on ElementType : Type1 |
For any element node whose type
annotationXQ is a complex type with
element-only content, the typed-value is undefined, and applying
fn:data
to such a node raises a type error.
Consequently, the data
on judgment is not defined on any element type whose
type
annotationXQ denotes a complex type
of element-only content. Attempting to apply data on to such a type raises a type
error.
Because we can derive complex types with element-only
content from complex types with mixed content (including
xs:anyType
), the data on judgment is also not defined on any
element type whose type
annotationXQ is a complex type of
mixed content (other than xs:untyped
, which is handled
above). Attempting to satisfy the data on judgment for such a type will fail,
and the processor will raise a type error.
Example
Consider the following variable and its corresponding static type.
$x : (element price { attribute currency { xs:string }, xs:decimal } | element price_code { xs:integer })
Applying the fn:data
function on that variable
results in the following type.
fn:data($x) : (xs:decimal | xs:integer)
Because the input type is a choice, applying the data on filter results in a
choice of simple types for the output of the fn:data
function.
fn:distinct-values
functionThe fn:distinct-values
function expects a sequence
of atomic values as input and returns a sequence of prime types,
which are defined in [8.4 Judgments for
FLWOR and other expressions on sequences].
fn:unordered
functionThe static semantics for fn:unordered
is computed
using prime and quantifier, which are defined
in [8.4 Judgments for FLWOR and other
expressions on sequences]. The type of the argument is
determined, and then prime(.) and quantifier(.) are applied to that type.
fn:error
functionThe fn:error function always has the none
type.
fn:min
, fn:max
,
fn:avg
, and fn:sum
functionsIntroduction
The semantics of aggregate functions convert any item of type
xs:untypedAtomic
in
the input sequence to xs:double
, then attempt to
promote all values in the input sequence to values that are
comparable. The static typing rules reflect the dynamic evaluation
rules.
The fn:sum
function has two forms. The first form
takes two arguments: The first argument is the input sequence and
the second argument is the value that should be returned if the
input sequence is empty. In case there is no second argument, the
value returned for an empty sequence is the xs:integer
value 0. The following static typing rule applies in the case there
is no second argument.
Notation
The type function convert_untypedAtomic takes a prime type and
converts all occurrences of the type xs:untypedAtomic
to a
target type. It is defined recursively as follows.
convert_untypedAtomic(xs:untypedAtomic , Type) |
= | Type | |
if not(FormalItemType = xs:untypedAtomic ) |
convert_untypedAtomic(FormalItemType, Type) | = | FormalItemType |
convert_untypedAtomic(empty ,
Type) |
= | empty |
|
convert_untypedAtomic(none ,
Type) |
= | none |
|
| convert_untypedAtomic(Type1 | Type2, Type) | = | convert_untypedAtomic(Type1, Type) | convert_untypedAtomic(Type2, Type) |
Notation
The function aggregate_quantifier converts the input type quantifier zero-or-more or zero-or-one to the result type quantifier zero-or-one, and converts the input type quantifier one or one-or-more, to the result type quantifier one.
aggregate_quantifier(? ) |
= | ? |
aggregate_quantifier(* ) |
= | ? |
aggregate_quantifier(1 ) |
= | 1 |
aggregate_quantifier(+ ) |
= | 1 |
Now we can define the static typing rules for the aggregate
functions. Note that the normalization rules of [4.1.5 Function Calls] will have
wrapped each argument in calls to fn:data
() and
fs:convert-simple-operand
()
(with a 'prototypical value' of type xs:double
). Thus,
static analysis of the call to an aggregate function is guaranteed
that any argument type is a subtype of xs:anyAtomicType
*, with no
occurrences of xs:untypedAtomic
.
First, we can quickly deal with fn:avg
. For the
purposes of static type analysis, fn:avg($arg)
is
equivalent to fs:div( fn:sum($arg,()), fn:count($arg)
)
Thus, we have the rule:
|
|||
|
|
|||
|
For the remaining aggregate functions (fn:min
,
fn:max
, and fn:sum
), the general approach
is as follows. First, we check that the input type(s) are
acceptable for the function. Then we construct the (first)
argument's prime type, a union of AtomicTypeNames. For each of the
latter, we find the 'base atomic type'. The union of these base
atomic types is the basis for the result type, which may finally be
adjusted for cardinality (fn:min
and
fn:max
) or for the effect of the second argument
(fn:sum
). In addition, we provide a rule for the
special case when the (first) argument has type 'empty'.
For fn:min
and fn:max
, the permitted
input types are all those for which ge(T,T) and le(T,T) are
defined. An empty input sequence yields an empty result.
|
|||
|
|
|||
|
|
|||||||||
|
|
|||||||||
|
For fn:sum
, the permitted input types for the first
argument are all those for which plus(T,T) is defined. If you pass
an empty sequence as the first argument, the function returns the
value of the second argument.
|
||||||||||
|
|
||||||||||
|
The second argument's contribution (if any) to the above result type is determined as follows. If the first argument could be the empty sequence, we add the type of the second argument to the result type. Otherwise, the type of the second argument is ignored.
fn:remove
functionThe static type for the fn:remove
function is
computed using prime and
quantifier, which are
defined in [8.4 Judgments for FLWOR and
other expressions on sequences]. Since one item may be
removed from the sequence, the resulting type is made optional.
fn:reverse
functionThe static type for the fn:reverse
function is
computed using prime and
quantifier, which are
defined in [8.4 Judgments for FLWOR and
other expressions on sequences].
fn:subsequence
functionThe static type of a call to fn:subsequence
is
computed using prime() and
quantifier(), which
are defined in [8.4 Judgments for FLWOR
and other expressions on sequences].
op:union
, op:intersect
, and
op:except
operatorsThe static semantics for op:union
is computed using
prime and quantifier, which are defined
in [8.4 Judgments for FLWOR and other
expressions on sequences]. The type of each argument is
determined, and then prime(.) and quantifier(.) are applied to the sequence type
(Type1, Type2).
The static semantics of op:intersect
is analogous
to that for op:union
. Because an intersection may be
empty, the result type is optional.
The static semantics of op:except
follows. The type
of the second argument is ignored as it does not contribute to the
result type. As with op:intersect
, the result of
op:except
may be the empty sequence.
fn:insert-before
functionThe static type for the fn:insert-before
function
is computed using prime
and quantifier, which
are defined in [8.4 Judgments for FLWOR
and other expressions on sequences].
fn:zero-or-one
, fn:one-or-more
, and
fn:exactly-one
functionsThe functions fn:zero-or-one
,
fn:one-or-more
, and fn:exactly-one
check
that the cardinality of a sequence is in the expected range. They
are useful to override the static type inferred for a given
query.
For example, in the following query, the user may know that all ISBN numbers are unique and therefore that the function always returns at most one book element. However, the static typing feature cannot infer a precise enough type and will raise a type error during static type analysis.
declare function book_with_isbn($isbn as xs:string) as schema-element(book)? { //book[@isbn=$isbn] }
In that query, the fn:zero-or-one
function can be
used to tell the type system that the cardinality is known to be
zero or one.
declare function book_with_isbn($isbn as xs:string) as schema-element(book)? { fn:zero-or-one(//book[@isbn=$isbn]) }
The static typing rules for those functions always infer a type with the cardinality indicated by that function.
This section defines auxiliary judgments used in defining the formal semantics. Many auxiliary judgments are used in both static typing and dynamic evaluation rules. Those auxiliary judgments that are used in only the static or dynamic semantics are labeled as such.
Introduction
This section defines several auxiliary judgments to access components of the [XPath/XQuery] type system. The first two judgments (derives from and substitutes for) are used to access the type and element name hierarchies in an XML Schema. The other judgments (name lookup, type lookup, extended by, adjusts to and expands to) are used to lookup the meaning of element or attribute types from the schema. These judgments are used in many expressions, notably in the specification of type matching (See [8.3 Judgments for type matching]), validation (See [F.1 Judgments for the validate expression]), and the static semantics of step expressions (See [8.2 Judgments for step expressions and filtering]).
Notation
The judgment
holds when TypeName1 derives from TypeName2. This judgment formalizes the definition of the
derives-from
function in Section
2.5.4 SequenceType MatchingXQ.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
USAddress derives from xs:anyType NYCAddress derives from USAddress NYCAddress derives from xs:anyType xsd:positiveInteger derives from xsd:integer xsd:integer derives from xs:anySimpleType fs:anon3 derives from xsd:positiveInteger fs:anon3 derives from xsd:integer fs:anon3 derives from xs:anySimpleType fs:anon3 derives from xs:anyType
Note
Derivation is a partial order. It is reflexive and transitive by the definition below.
Semantics
This judgment is specified by the following rules.
Every type name derives from itself.
Every type name derives from the type it is declared to derive from by extension or restriction.
|
|||
|
|
|||
| statEnv |- TypeName derives from BaseTypeName |
|
|||
|
|
|||
| statEnv |- TypeName derives from BaseTypeName |
The above rules all require that the type names be defined in the static context, but [XPath/XQuery] permits references to "unknown" type names, i.e., type names that are not defined in the static context. An unknown type name might be encountered, if a module in which the given type name occurs does not import the schema in which the given type name is defined. In this case, an implementation is allowed (but is not required) to provide an implementation-dependent mechanism for determining whether the unknown type name is the same as or derived by restriction from the expected type name. The following rule formalizes this implementation dependent mechanism.
|
||
|
|
||
| statEnv |- TypeName1 derives from TypeName2 |
The derivation relation is transitive.
The substitutes judgment is used to know whether an element name is in the substitution group of another element name.
Notation
The judgment
holds when ElementName1 substitutes for ElementName2.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
usaddress substitutes for address nyaddress substitutes for usaddress nyaddress substitutes for address
Note
Substitution is a partial order. It is reflexive and transitive by the definition below. It is asymmetric because no cycles are allowed in substitution groups.
Semantics
The substitutes judgment for element names is specified by the following rules.
Every element name substitutes for itself.
Every element name substitutes for the element it is declared to substitute for.
|
|||
|
|
|||
| statEnv |- ElementName substitutes for BaseElementName |
Substitution is transitive.
The name lookup judgment is used in the definition of the matches judgment, which takes a value and a type and determines whether the value matches, or is an instance of, the given type. Both name lookup and matches are used in the dynamic semantics.
The name lookup judgment takes an element(attribute) name (derived from a node value) and an element(attribute) type and if the element(attribute) name matches the corresponding name in the element(attribute) type, the judgment yields the type's corresponding type reference and for elements, its nillable property.
Notation
The judgment
holds when the given element name matches the given element type and requires that the element be nillable as indicated and have the given type reference.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
comment name lookup element comment yields of type xsd:string size name lookup element size nillable of type xs:integer yields nillable of type xsd:string apt name lookup element apt yields of type fs:anon3 nycaddress name lookup element address yields of type NYCAddress
Note that when the element name is in a substitution group, the
name lookup returns the type name corresponding to the original
element name (here the type NYCAddress
for the element
nycaddress
, instead of Address
for the
element address
).
Semantics
This judgment is specified by the following rules.
If the element type is a reference to a global element, then name lookup yields the type reference in the element declaration for the given element name. The given element name must be in the substitution group of the global element.
|
|
| statEnv |- ElementName1 name lookup element ElementName2 yields OptNillable TypeReference |
If the given element name matches the element name in the element type, and the element type contains a type reference, then name lookup yields that type reference.
|
|
| statEnv |- ElementName name lookup element ElementName OptNillable TypeReference yields OptNillable TypeReference |
If the element type has no element name but contains a type reference, then name lookup yields the type reference.
|
|
| statEnv |- ElementName name lookup element * TypeReference yields TypeReference |
If the element type has no element name and no type reference,
then name lookup yields xs:anyType
.
|
|
statEnv |- ElementName name lookup element * yields of type
xs:anyType |
Notation
The judgment
holds when matching an attribute with the given attribute name against the given attribute type matches the type reference.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
orderDate name lookup attribute orderDate of type xsd:date yields of type xsd:date? orderDate name lookup attribute of type xsd:date yields of type xsd:date?
Semantics
This judgment is specified by the following rules.
If the attribute type is a reference to a global attribute, then name lookup yields the type reference in the attribute declaration for the given attribute name.
|
|||
|
|
|||
| statEnv |- AttributeName name lookup attribute AttributeName yields TypeReference |
If the given attribute name matches the attribute name in the attribute type, and the attribute type contains a type reference, then name lookup yields that type reference.
|
|
| statEnv |- AttributeName name lookup attribute AttributeName TypeReference yields TypeReference |
If the attribute type has no attribute name but contains a type reference, then name lookup yields the type reference.
|
|
| statEnv |- AttributeName name lookup attribute * TypeReference yields TypeReference |
If the attribute type has no attribute name and no type
reference, then name lookup yields
xs:anySimpleType
.
|
|
statEnv |- AttributeName name lookup
attribute * yields of type
xs:anySimpleType |
The type lookup judgments are used to obtain the appropriate type reference for an attribute or element.
Notation
The judgment
holds when the element type is optionally nillable and has the given type reference.
Semantics
The element type lookup judgments are specified by the following rules.
A reference to a global element yields the type reference in the global element declaration with the given element name.
|
|||
|
|
|||
| statEnv |- element ElementName type lookup OptNillable TypeReference |
In the case of a local element type, type lookup yields the corresponding type reference.
If the element type has no element name but contains a type reference, then type lookup yields that type reference.
|
|
| statEnv |- element * OptNillable TypeReference type lookup TypeReference |
If the element type has no element name and no type reference,
then lookup yields xs:anyType
.
|
|
statEnv |- element * type lookup of type
xs:anyType |
Notation
The judgment
holds when the attribute type has the given type reference.
Semantics
This judgment is specified by the following rules.
A reference to a global attribute yields the type reference in the global attribute declaration with the given attribute name.
|
|||
|
|
|||
| statEnv |- attribute AttributeName type lookup TypeReference |
If the attribute name is not defined, i.e., it is not declared
in the in-scope schema definitions, then the attribute's default
type is xs:untypedAtomic
.
|
|||
|
|
|||
statEnv |- attribute AttributeName type
lookup of type xs:untypedAtomic |
In the case of a local attribute type, type lookup yields the corresponding type reference.
|
|
| statEnv |- attribute AttributeName TypeReference type lookup TypeReference |
If the attribute type has no attribute name but contains a type reference, then type lookup yields the type reference.
|
|
| statEnv |- attribute * TypeReference type lookup TypeReference |
If the attribute type has no attribute name and no type
reference, then type lookup yields
xs:anySimpleType
.
|
|
statEnv |- attribute * type
lookup of type xs:anySimpleType |
Notation
The judgment
holds when the result of extending Type1 by Type2 is Type. This judgment is used in the definition of type expansion [8.1.9 Type expansion], which expands a type to include the union of all types derived from the given type,
Semantics
This judgment is specified by the following rules.
| statEnv |- Type1 = AttributeModel1 , ElementModel1 statEnv |- Type2 = AttributeModel2 , ElementModel2 |
|
|
| statEnv |- Type1 extended by Type2 is (AttributeModel1 & AttributeModel2) , ElementModel1 , ElementModel2 |
Notation
The judgment
holds when the result of creating a mixed content from Type1 is Type2.
Semantics
This judgment is specified by the following rule, which
interleaves the element content with a sequence of text nodes and
adds a union of xs:anyAtomicType
values.
The xs:anyAtomicType
sequence
is required because it is possible to derive an element containing
only atomic values from an element that is mixed.
| statEnv |- Type = AttributeModel , ElementModel |
|
|
statEnv |- Type mixes to AttributeModel , ( ElementModel & text* |
xs:anyAtomicType
*) |
In the [XPath/XQuery] type system, a complex-type declaration does not include the implicit attributes and nodes that may be included in the type. Type adjustment takes a complex type and adjusts it to include implicit attributes and nodes. In particular, type adjustment:
adds the four (optional) built-in attributes xsi:type, xsi:nil, xsi:schemaLocation, or xsi:noNamespaceSchemaLocation,
interleaves the type with a sequence of comments and processing-instructions, and
if the complex type is mixed, interleaves the type with a
sequence of text nodes and xs:anyAtomicType
.
Notation
The judgment
holds when the second type is the same as the first after the first has been adjusted as described above.
Semantics
This judgment is specified by the following rules.
If the type is flagged as mixed, then mix the type and extend it by the built-in attributes.
|
||||
|
|
||||
| statEnv |- mixed Type1 adjusts to Type4 |
Otherwise, just extend the type by the built-in attributes.
|
|||
|
|
|||
| statEnv |- Type1 adjusts to Type3 |
Schema defines four built-in attributes that can appear on any element in the document without being explicitly declared in the schema. Those four attributes need to be added inside content models when doing matching. The four built-in attributes of Schema are declared as follows.
define attribute xsi:type of type xs:QName; define attribute xsi:nil of type xs:boolean; define attribute xsi:schemaLocation of type fs:anon; define type fs:anon1 { xs:anyURI* }; define attribute xsi:noNamespaceSchemaLocation of type xs:anyURI;
For convenience, a type that is an all group of the four built-in XML Schema attributes is defined.
BuiltInAttributes = attribute xsi:type ? & attribute xsi:nil ? & attribute xsi:schemaLocation ? & attribute xsi:noNamespaceSchemaLocation ?
The expands to judgment is one of the most important static judgments. It is used in the static semantics of the child axis [<IP_ADDRESS> Static semantics of axes], which is used in the definition of many other rules that extract element types from an arbitrary content type.
The judgment takes a type name and computes the union of all types derived from the given type. If the type is nillable, it also makes sure the content model allows the empty sequence. If the type is mixed, it also adjusts the type to include the mixed content model. The judgment depends on the union interpretation of judgment to recursively compute all derived types.
Notation
The judgment
holds when expanding the type specifier results in the given type.
Semantics
This judgment is specified by the following rules.
If the type is nillable, then it expands into an optional type.
| statEnv |- TypeReference expands to Type |
|
|
| statEnv |- nillable TypeReference expands to Type? |
The type definition for the type reference is contained in its expansion.
|
|||||
|
|
|||||
| statEnv |- of type TypeName expands to Type3 |
In case the type is xs:untyped
, the type does not
need to be adjusted as is required for other XML Schema types. See
the corresponding definition in [3.5.1 Predefined Schema
Types].
|
|||
|
|
|||
statEnv |- of type xs:untyped expands to Type1 |
Notation
The judgment
holds when the type TypeU is the union of all types derived (directly and indirectly, by extension and restriction) from the type defined by Definition.
Semantics
This judgment is specified by the following rules.
|
|||||||||
|
|
|||||||||
|
The auxilliary judgment
looks "up" the type hierarchy to find out what OptDerivation contributes to the content model of a derived type. It is defined as follows:
|
||||
|
|
||||
|
|
|
||
|
|
|
||
|
The auxiliary judgment:
holds when Type2 is the result of making Type1 'mixed' or not, as determined by OptMixed. It is defined as follows:
|
|
||
|
Finally, the auxiliary judgment:
is defined informally: all type definitions in statEnv.typeDefn that involve "restricts TypeName" or "extends TypeName" are returned as a list (in arbitrary order) of Definitions.
Examples
Note that this expansion does not enforce the unique
particule attribution property specified by XML Schema in the
resulting content models. Implementations may want to implement an
equivalent alternative expansion that enforces that property. For
example, expanding type T1
below yields the following
type that is not one-deterministic:
define type T1 { element a } define type T2 extends T1 { element b } union interpretation of define type T1 { element a } is (element a | element a, element b)
An implementation might want to infer the equivalent content model that verifies the unique particule attribution property of XML Schema:
union interpretation of define type T1 { element a } is (element a, (() | element b))
Introduction
Step expressions are one of the elementary operations in [XPath/XQuery]. Steps select nodes reachable from the root of an XML tree. Defining the semantics of step expressions requires a detailed analysis of all the possible cases of axis and node tests.
This section introduces auxiliary judgments used to define the semantics of step expressions. The has principal judgment ([8.2.1 Principal Node Kind]) captures the notion of principal node kind in XPath. The Axis judgments ([8.2.2 Auxiliary judgments for axes]) define the static and dynamic semantics of all axes, and the Node Test judgments ([8.2.3 Auxiliary judgments for node tests]) define the static and dynamic semantics of all node tests. The filter judgment accesses the value of an attribute and is used in the definition of validation ([F Auxiliary Judgments for Validation]).
Notation
The following auxiliary grammar production describes principal node kinds (See [XML Path Language (XPath) 2.0 (Second Edition)]).
| [64 (Formal)] | PrincipalNodeKind |
::= | "element" | "attribute" | "namespace" |
Notation
The judgment
holds when PrincipalNodeKind is the principal node kind for Axis.
Example
For example, the following judgments hold.
child:: principal element descendant:: principal element preceding:: principal element attribute:: principal attribute namespace:: principal namespace
Semantics
This judgment is specified by the following rules.
The principal node type for the attribute axis is attribute.
|
|
attribute:: has principal attribute |
The principal node type for the namespace axis is namespace.
|
|
namespace:: has principal namespace |
The principal node type for all other axis is element.
Axis !=
attribute:: Axis !=
namespace:: |
|
|
| Axis has principal element |
Notation
The following judgment
holds when applying the axis Axis on type Type1 yields the type Type2.
The following two judgments are used in the definition of axis. The judgment
only applies to a type that is a valid element content type and holds when Type1 has the content type Type2. The judgment separates the attribute types from the other node or atomic-valued types of the element content type and yields the non-attribute types.
The judgment
only applies to a type that is a valid element content type and holds when Type1 has attribute types Type2. The judgment yields the attribute types of the element content type.
Example
For example, the following judgments hold.
axis child:: of element of type xs:string : text axis child:: of element items of type Items : element item of type fs:anon1* axis child:: of element purchaseOrder : element shipTo of type USAddress, element billTo of type USAddress, element ipo:comment?, element items of type Items axis attribute:: of element of type xs:string : empty attribute partNum of type SKU, element item of type fs:anon1* has-node-content element item of type fs:anon1* attribute partNum of type SKU, element item of type fs:anon1* has-attribute-content attribute partNum of type SKU (attribute partNum of type SKU, element item of type fs:anon1*) | (attribute orderDate of type xs:date?, element shipTo of type USAddress, element billTo of type USAddress, element comment?, element items of type Items) has-node-content (element item of type fs:anon1*) | (element shipTo of type USAddress, element billTo of type USAddress, element comment?, element items of type Items) (attribute partNum of type SKU, element item of type fs:anon1*) | (attribute orderDate of type xs:date?, element shipTo of type USAddress, element billTo of type USAddress, element comment?, element items of type Items) has-attribute-content (attribute partNum of type SKU) | (attribute orderDate of type xs:date?)
Semantics
The following rules compute the type of the axis expression when applied to each item type in the content model.
|
||
|
|
||
| statEnv |- axis Axis of Type1 OccurrenceIndicator : Type2 OccurrenceIndicator |
|
|||
|
|
|||
| statEnv |- axis Axis of Type1&Type2 : Type3&Type4 |
|
|||
|
|
|||
| statEnv |- axis Axis of Type1,Type2 : Type3,Type4 |
|
|||
|
|
|||
| statEnv |- axis Axis of Type1|Type2 : Type3|Type4 |
The rules in the following subsections specify how to compute the type of each axis applied to an item type.
self
axisSemantics
Applying the self axis to a node type results in the same node type.
child
axisSemantics
In the case of an element type, the static type of the child axis is obtained by type lookup and expansion of the resulting type. Note that the expands to judgment yields the type that corresponds to a given type name. Because the meaning of a type name includes the definitions of all type names derived by extension and restriction from the given type name, expands to yields the union of all the type definitions of all type names derived from the input type name. Each type in the union contains the complete definition of the type name, i.e., it includes built-in attributes and, if necessary, processing-instruction, comment, and text types.
After type expansion, the judgment has node content is applied to each type in the union. The resulting type is the union of all non-attribute types in the expanded type.
|
||||||
|
|
||||||
statEnv |- axis child:: of ElementType : Type1'
| ... | Typen' |
If the type is a sequence of attributes, then the content type
is empty
.
If the type is attributes followed by a simple type, the content type is zero-or-one text nodes. The resulting type is optional since an expression returning the empty sequence results in no text node being constructed.
|
||||
|
|
||||
| statEnv |- Type has node content text? |
In the case of an element type with complex content type, the content type is simply the non-attribute part of the complex content type.
|
||||
|
|
||||
| statEnv |- Type has node content Type2 |
In the case of an attribute type, the static type of the child axis is empty.
|
|
statEnv |- axis child:: of AttributeType :
empty |
In the case of a text node type, the static type of the child axis is empty.
In the case of a comment node type, the static type of the child axis is empty.
In the case of a processing-instruction node type, the static type of the child axis is empty.
In case of a document node type, the static type of the child axis is the type of the document node content, interleaved with a sequence of comments and processing-instructions.
attribute
axisSemantics
The static type for the attribute axis is computed in a similar way as the static type for the child axis. As above, the expands to judgment may yield a union type. After type expansion, the judgment has attribute content is applied to each type in the union.
|
||||||
|
|
||||||
statEnv |- axis attribute:: of ElementType : Type1'
| ... | Typen' |
When applied to an element type, has attribute content yields the type of the element's content that are attributes.
|
||||
|
|
||||
| statEnv |- Type has attribute content Type1 |
In case of an attribute type, the static type of the attribute axis is empty.
|
|
statEnv |- axis attribute:: of AttributeType :
empty |
In case of a text node type, the static type of the attribute axis is empty.
In case of a comment node type, the static type of the attribute axis is empty.
In case of a processing-instruction node type, the static type of the attribute axis is empty.
In case of a document node type, the static type of the attribute axis is the empty.
parent
axisSemantics
The type for the parent of an element type, a text node type, a PI node type, or a comment node type is either an element, a document, or empty.
The type for the parent of an attribute node is an element or empty.
|
|
statEnv |- axis parent:: of AttributeType : element *? |
The type for the parent of a document node type is always empty.
|
|
statEnv |- axis parent:: of DocumentType :
empty |
namespace
axisSemantics
This document does not specify inference rules for the namespace axis (which is allowed, though deprecated, in XPath 2.0, and is not allowed in XQuery 1.0). Implementations choosing to support the namespace axis will need to define an additional node kind for namespace nodes in the type hierarchy, and to add the appropriate inference rules.
descendant
axisSemantics
The types for the descendant axis is obtained as the closure of the type of the child axis. This is expressed by the following inference rule.
|
||||||
|
|
||||||
statEnv |- axis descendant:: of Type : (prime(Type1)
| ... | prime(Typen))* |
Note
Note that the last premise in the above rule terminates the recursion. The rule computes the n-th type Typen such that applying the child axis one more time does not add any new item type to the union. This condition is guaranteed to hold at some point, because the number of item types is bounded by all of the item types defined in the in-scope schema definitions.
descendant-or-self
axisSemantics
The type for the descendant-or-self axis is the union of the type for the self axis and for the descendant axis.
ancestor
axisSemantics
The type for the ancestor axis is computed similarly as for the descendant axis.
Note that this rule will always result in the type
(element * | document)*
type, but this formulation is
preferred for consistency, and in case the static typing for the
parent axis gets improved in a future version.
Notation
The following judgment
holds when applying the axis Axis on Value1 yields Value2:
Example
For example, the following judgments hold.
axis child:: of element sizes { text { "1 2 3" } } => text { "1 2 3" } axis attribute:: of element weight of type xs:integer { attribute xsi:type of type xs:QName { "xs:integer" of type xs:QName }, 42 of type xs:integer } => attribute xsi:type of type xs:QName { "xs:integer" of type xs:QName }
Semantics
This judgment is specified by the following rules.
The first set of rules are used to process the axis judgment on each individual item in the input sequence.
|
|||
|
|
|||
| dynEnv |- axis Axis of Value1,Value2 => Value3,Value4 |
The following rules specifies how the value filter judgment is applied on each Axis.
The self axis just returns the context node.
The child, parent, attribute and namespace axis are specified as follows.
|
|
dynEnv |- axis child:: of element ElementName { AttributeValue,ElementValue } => ElementValue |
|
|
dynEnv |- axis attribute:: of element ElementName { AttributeValue,ElementValue } => AttributeValue |
The descendant, descendant-or-self, ancestor, and ancestor-or-self axis are implemented through recursive application of the children and parent filters.
|
|||
|
|
|||
dynEnv |- axis descendant:: of NodeValue => Value1, Value2 |
|
|||
|
|
|||
dynEnv |- axis descendant-or-self::
of NodeValue => Value1, Value2 |
|
|||
|
|
|||
dynEnv |- axis ancestor:: of NodeValue => Value1, Value2 |
|
|||
|
|
|||
dynEnv |- axis ancestor-or-self:: of NodeValue => Value1, Value2 |
In all the other cases, the axis application results in an empty sequence, and the following judgment holds.
A node test may be a name test or a kind test. In the static and dynamic semantics, we begin with name tests, followed by kind tests.
Notation
The following judgment
holds when applying the node test NodeTest on the type Type1 in the context of the given principal node kind, yields the type Type2.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
test shipTo with element of element shipTo of type USAddress, element billTo of type USAddress, element ipo:comment?, element items of type Items : element shipTo of type USAddress
Semantics
This judgment is specified by the following rules.
The first set of rules is similar to that for axes, and are used to process the content each individual item type in the input content model.
| statEnv |- test NodeTest with PrincipalNodeKind of Type1 : Type2 |
|
|
| statEnv |- test NodeTest with PrincipalNodeKind of Type1 OccurrenceIndicator : Type2 OccurrenceIndicator |
|
|||
|
|
|||
| statEnv |- test NodeTest with PrincipalNodeKind of Type1 & Type2 : Type3 & Type4 |
|
|||
|
|
|||
| statEnv |- test NodeTest with PrincipalNodeKind of Type1 , Type2 : Type3 , Type4 |
|
|||
|
|
|||
| statEnv |- test NodeTest with PrincipalNodeKind of Type1|Type2 : Type3|Type4 |
The following rules specify how the test judgment apply to node tests in the context of a principal node kind. We start with name tests followed by kind tests.
Name tests on elements and attributes always compute the most
specific type possible. For example, if $v
is bound to
an element with a computed name, the type of $v
is
element
. The static type computed for the expression
$v/self::foo
is element foo of type
xs:anyType
, which makes use of foo
in the name
test to compute a more specific type. Also note that each case of
name matching restricts the principal node kind appropriately.
|
|||
|
|
|||
| statEnv |- test QName2 with element of element QName1 OptTypeSpecifier : element QName1 OptTypeSpecifier |
|
||||
|
|
||||
|
|
|
statEnv |- test QName2 with element of element * OptTypeSpecifier : element
QName2 OptTypeSpecifier ? |
|
|||
|
|
|||
statEnv |- test
*: LocalPart2
with element
of element
QName1 OptTypeSpecifier : element
QName1 OptTypeSpecifier |
|
||||
|
|
||||
|
|
|
statEnv |- test
*: LocalPart2
with element
of element *
OptTypeSpecifier
: element *
OptTypeSpecifier
? |
|
||||
|
|
||||
| statEnv |- test Prefix2:* with element of element QName1 OptTypeSpecifier : element QName1 OptTypeSpecifier |
|
|||||
|
|
|||||
|
|
|
statEnv |- test Prefix2:* with element of element * OptTypeSpecifier : element * OptTypeSpecifier ? |
|
|
statEnv |- test * with element of ElementType : ElementType |
Similar static typing rules apply to the attribute name tests:
|
|||
|
|
|||
| statEnv |- test QName2 with attribute of attribute QName1 OptTypeReference : attribute QName1 OptTypeReference |
|
||||
|
|
||||
|
|
|
statEnv |- test QName2 with attribute of attribute * OptTypeReference : attribute
QName2 OptTypeReference ? |
|
|||
|
|
|||
statEnv |- test
*: LocalPart2
with attribute
of attribute
QName1 OptTypeReference : attribute
QName1 OptTypeReference |
|
||||
|
|
||||
|
|
|
statEnv |- test
*: LocalPart2
with attribute
of attribute *
OptTypeReference
: attribute *
OptTypeReference
? |
|
||||
|
|
||||
statEnv |- test Prefix2:* with attribute of attribute QName1 OptTypeReference : attribute
QName1 OptTypeReference |
|
|||||
|
|
|||||
|
|
|
statEnv |- test Prefix2:* with attribute of attribute * OptTypeReference : attribute * OptTypeReference ? |
|
|
statEnv |- test * with attribute of AttributeType : AttributeType |
All the rules for typing the document, element, and attribute kind tests are similar. First, the document, element, or attribute test is normalized to the equivalent document, element, or attribute type by applying the []sequencetype normalization rule to the kind test.
After normalization of the kind test as an XQuery type, that type is compared to the expression's inferred type. If the latter is a subtype of the former other, then the kind test yields the smaller type.
Document kind test
Semantics
If the type of the expression is a subtype of the document kind test, then we are guaranteed that during evaluation, the expression's value will always match the document kind test, and therefore the type of the entire expression is the type of the input expression.
|
|||
|
|
|||
| statEnv |- test DocumentTest with element of Type1 : Type1 |
Conversely, if the type of the document kind test is a subtype of the expression, then during evaluation, the expression's value may or may not match the document kind test, and therefore the type of the entire expression is zero-or-one of the type of the document kind test.
|
|||
|
|
|||
| statEnv |- test DocumentTest with element of Type1 : DocumentType? |
If the types of the expression and document kind test are unrelated, then we apply the kind test rule recursively on the element types, which may yield a non-empty type.
|
|||||
|
|
|||||
| statEnv |- test document-node (ElementTest) with element of document { Type1 } : document { Type2 } |
If there is no non-empty type, then the kind test yields the empty type.
|
||||||
|
|
||||||
| statEnv |- test document-node (ElementTest) with element of document { Type1 } : empty |
Element kind test
Semantics
The rules for the element kind test are similar to those for the document kind test.
If the type of the expression is a subtype of the element kind test, then we are guaranteed that during evaluation, the expression's element value will always match the element kind test, and therefore the type of the entire expression is the type of the input expression.
|
|||
|
|
|||
| statEnv |- test ElementTest with element of Type1 : Type1 |
Conversely, if the type of the element kind test is a subtype of the expression, then during evaluation, the expression's element value may or may not match the element kind test, and therefore the type of the entire expression is zero-or-one of the type of the element kind test.
|
|||
|
|
|||
| statEnv |- test ElementTest with element of Type1 : ElementType? |
If the types of the expression and element kind test are unrelated (i.e., neither type is a subtype of the other), then we must compare the structure of the type of the element test with the type of the element expression, as an element type or test may contain wildcards.
In the first case, the element kind test contains an element name and a type name and the input expression's type contains only a type name. If the input expression's content type is a subtype of the element kind test's content type, then the type of the entire expression is zero-or-one of an element with the given name and the input expression's content type.
|
||||
|
|
||||
| statEnv |- test ElementTest with element of element * TypeSpecifier2 : element ElementName1 TypeSpecifier2? |
In the second case, the structure of the input types is reversed: The input expression's type contains an element name and a type name and the element kind test's type contains only a type name. If the element kind test's content type is a subtype of the input expression's content type, then the type of the entire expression is zero-or-one of an element with the given name and the element kind test's content type.
|
||||
|
|
||||
| statEnv |- test ElementTest with element of element ElementName2 TypeSpecifier2 : element ElementName2 TypeSpecifier1? |
Lastly, if none of the above rules holds, then the type of the input expression is empty.
|
||||||||
|
|
||||||||
| statEnv |- test ElementTest with element of element ElementNameOrWildcard2 TypeSpecifier2 : empty |
Attribute kind test
Semantics
The rules for the attribute kind test are isomorphic to those for element kind test.
If the type of the expression is a subtype of the attribute kind test, then we are guaranteed that during evaluation, the expression's attribute value will always match the attribute kind test, and therefore the type of the entire expression is the type of the input expression.
|
|||
|
|
|||
| statEnv |- test AttributeTest with attribute of Type1 : Type1 |
Conversely, if the type of the attribute kind test is a subtype of the expression, then during evaluation, the expression's attribute value may or may not match the attribute kind test, and therefore the type of the entire expression is zero-or-one of the type of the attribute kind test.
|
|||
|
|
|||
| statEnv |- test AttributeTest with attribute of Type1 : AttributeType? |
If the types of the expression and attribute kind test are unrelated (i.e., neither type is a subtype of the other), then we must compare the structure of the type of the attribute test with the type of the attribute expression, as an attribute type or test may contain wildcards.
In the first case, the attribute kind test contains an attribute name and a type name and the input expression's type contains only a type name. If the input expression's content type is a subtype of the attribute kind test's content type, then the type of the entire expression is zero-or-one of an attribute with the given name and the input expression's content type.
|
||||
|
|
||||
| statEnv |- test AttributeTest with attribute of attribute * TypeReference2 : attribute AttributeName1 TypeReference2? |
In the second case, the structure of the input types is reversed: The input expression's type contains an attribute name and a type name and the attribute kind test's type contains only a type name. If the attribute kind test's content type is a subtype of the input expression's content type, then the type of the entire expression is zero-or-one of an attribute with the given name and the attribute kind test's content type.
|
||||
|
|
||||
| statEnv |- test AttributeTest with attribute of attribute AttributeName2 TypeReference2 : attribute AttributeName2 TypeReference1? |
Lastly, if none of the above rules holds, then the type of the input expression is empty.
|
||||||||
|
|
||||||||
| statEnv |- test AttributeTest with attribute of attribute AttributeName2 TypeReference2 : empty |
Processing instruction, comment, and text kind tests
Semantics
| [PITest]sequencetype = processing-instruction * |
|
|
| statEnv |- test PITest with PrincipalNodeKind of ProcessingInstructionType : ProcessingInstructionType |
A processing-instruction node test with a string literal or NCName matches a processing instruction whose target has the given name.
| [PITest]sequencetype = processing-instruction NCName |
|
|
| statEnv |- test PITest with PrincipalNodeKind of processing-instruction NCName : processing-instruction NCName |
| [PITest]sequencetype = processing-instruction NCName |
|
|
| statEnv |- test PITest with PrincipalNodeKind of processing-instruction * : processing-instruction NCName ? |
If none of the above rules applies then the node test returns the empty sequence, and the following dynamic rule is applied:
Notation
The following judgment
holds when applying the node test NodeTest on Value1 in the context of the PrincipalNodeKind yields Value2:
Example
For example, the following judgments hold.
test node() with element of text { "1 2 3" } => text { "1 2 3" } test size with element of text { "1 2 3" } => () test foo:* with element of (element foo:a of type xs:int { 1 }, element foo:a of type xs:int { 2 }, element bar:b of type xs:int { 3 }, element bar:c of type xs:int { 4 }, element foo:d of type xs:int { 5 }) => (element foo:a of type xs:int { 1 }, element foo:a of type xs:int { 2 }, (), (), element foo:d of type xs:int { 5 })
Note
The last example illustrates how a test judgment operates on a sequence of nodes, applying the test on each node in the sequence individually, while preserving the structure of the sequence.
Semantics
This judgment is specified by the following rules.
The first set of rules are similar to those for axes, and are used to process the test judgment on each individual item in the input sequence.
|
|||
|
|
|||
| dynEnv |- test NodeTest with PrincipalNodeKind of Value1,Value2 => Value3,Value4 |
The following rules specify how the value filter judgment is applied on a name test in the context of a principal node kind.
Semantics
|
||||||
|
|
||||||
| dynEnv |- test Prefix:LocalPart with PrincipalNodeKind of NodeValue => NodeValue |
|
||
|
|
||
dynEnv |- test * with PrincipalNodeKind of NodeValue => NodeValue |
|
|||||
|
|
|||||
dynEnv |- test Prefix:* with
PrincipalNodeKind of NodeValue => NodeValue |
All the rules for evaluating the document, element, and attribute kind tests are similar. First, the document, element, or attribute test is normalized to the equivalent document, element, or attribute type by applying the []sequencetype normalization rule. As explained in [3.5.3 SequenceType Syntax], SequenceTypes are normalized to XQuery types whenever a dynamic evaluation or static typing rule requires the corresponding type. The reason for this deviation from the processing model is that the result of SequenceType normalization is not part of the [XPath/XQuery] core syntax.
After normalization of the SequenceType to an XQuery type, the document, element, or attribute value is simply matched against the XQuery type. If the value matches the type, then the judgment yields the value, otherwise the judgment yields the empty sequence.
Document kind test
Semantics
|
|||
|
|
|||
| dynEnv |- test DocumentTest with element of DocumentValue => DocumentValue |
|
|||
|
|
|||
| dynEnv |- test DocumentTest with element of DocumentValue => () |
Element kind test
Semantics
|
|||
|
|
|||
| dynEnv |- test ElementTest with element of ElementValue => ElementValue |
|
|||
|
|
|||
| dynEnv |- test ElementTest with element of ElementValue => () |
Attribute kind test
Semantics
|
|||
|
|
|||
| dynEnv |- test AttributeTest with attribute of AttributeValue => AttributeValue |
|
|||
|
|
|||
| dynEnv |- test AttributeTest with attribute of AttributeValue => () |
Processing instruction, comment, and text kind tests
Semantics
|
||
|
|
||
dynEnv |- test processing-instruction()
with
PrincipalNodeKind of NodeValue => NodeValue |
|
|||||
|
|
|||||
dynEnv |- test processing-instruction(
StringLiteral ) with PrincipalNodeKind of NodeValue => NodeValue |
|
||
|
|
||
dynEnv |- test processing-instruction()
with
PrincipalNodeKind of NodeValue => () |
|
||
|
|
||
dynEnv |- test comment() with
PrincipalNodeKind of NodeValue => NodeValue |
|
||
|
|
||
dynEnv |- test comment() with
PrincipalNodeKind of NodeValue => () |
|
||
|
|
||
dynEnv |- test text() with PrincipalNodeKind
of NodeValue => NodeValue |
|
||
|
|
||
dynEnv |- test text() with PrincipalNodeKind
of NodeValue => () |
The node()
node test is true for all nodes.
Therefore, the following rule does not have any precondition
(remember that an empty upper part in the rule indicates that the
rule is always true).
If none of the above rules applies then the node test returns the empty sequence, and the following dynamic rule is applied:
Introduction
XQuery supports type declarations on variable bindings, and
several operations on types (typeswitch
,
instance of
, etc). This section describes judgments
used for the specification of the semantics of those
operations.
The "match" judgment specifies formally type matching. It takes as input a value and a type and either succeeds or fails. It is used in matching parameters against function signatures, type declarations, and matching values against cases in "typeswitch". An informal description of type matching is given in Section 2.5.4 SequenceType MatchingXQ.
The "subtyping" judgment takes two types and succeeds if all values matching the first type also match the second. It is used to define the static semantics of operations using type matching.
Notation
The judgment
holds when the given value matches the given type.
Example
For example, assuming the extended XML Schema given in section [2.4.5 Example of a complete Schema], then the following judgments hold.
element comment of type xsd:string { "This is not important" } matches element comment of type xsd:string (element apt of type fs:anon3 { 2510 }, element apt of type fs:anon3 { 2511 }) matches element apt+ () matches element usaddress? element usaddress of type USAddress { element name of type xsd:string { "The Archive" }, element street of type xsd:string { "Christopher Street" }, element city of type xsd:string { "New York" }, element state of type xsd:string { "NY" }, element zip of type xsd:decimal { 10210 } } matches element usaddress?
Semantics
We start by giving the inference rules for matching an item value with an item type.
An atomic value matches an atomic type if its type annotationXQ derives from the atomic type. The value itself is ignored -- this is checked as part of validation.
| statEnv |- AtomicTypeName1 derives from AtomicTypeName2 |
|
|
| statEnv |- AtomicValueContent of type AtomicTypeName1 matches AtomicTypeName2 |
A text node matches text.
A comment node matches comment.
A processing-instruction node matches the general processing-instruction type, and also the particular processing-instruction type that shares its PITarget.
A document node matches a document type if the node's content matches the document type's corresponding content type.
The rules for matching an element value with an element type are more complicated. When an element value is not nilled, the element matches an element type if the element name and the element type resolve to some type name, and the element value's type annotationXQ is derived from the resolved type name. Note that there is no need to check structural constraints on the value since those have been checked during XML Schema validation and the value is assumed to be consistent with its type annotationXQ.
|
|||||
|
|
|||||
| statEnv |- element ElementName of type TypeName { Value } matches ElementType |
Note
Type matching uses the name lookup judgment defined in [8.1.3 Element and attribute name lookup (Dynamic)].
In the case the element has been nilled, that is there exists and xsi:nil attribute set to true in the element value, the following rule checks that the type is nillable.
|
||||
|
|
||||
| statEnv |- element ElementName of type TypeName { Value } matches ElementType |
The rule for attributes is similar, but does not require the check for the xsi:nil attribute.
|
|||
|
|
|||
| statEnv |- attribute AttributeName of type TypeName { SimpleValue } matches AttributeType |
A type can also be a sequence of items, in that case the matching rules also need to check whether the constraints described by the type as a regular expression hold. This is specified by the following rules.
The empty sequence matches the empty sequence type.
If two values match two types, then their sequence matches the corresponding sequence type.
|
|||
|
|
|||
| statEnv |- Value1,Value2 matches Type1,Type2 |
If a value matches a type, then it also matches a choice type where that type is one of the choices.
If two values match two types, then their interleaving matches the corresponding all group.
|
||||
|
|
||||
| statEnv |- Value matches Type1 & Type2 |
An optional type matches a value of that type or the empty sequence.
The following rules are used to match a value against a sequence of zero (or one) or more types.
| statEnv |- Value1 matches Type statEnv |- Value2 matches Type* |
|
|
| statEnv |- Value1, Value2 matches Type* |
| statEnv |- Value1 matches Type statEnv |- Value2 matches Type* |
|
|
| statEnv |- Value1, Value2 matches Type+ |
Note
The above definition of type matching, although complete and precise, does not give a simple means to compute type matching. Notably, some of the above rules can be non-deterministic (e.g., the rule for matching of choice or repetition).
The structural component of the [XPath/XQuery] type system can be modeled by regular expressions. Regular expressions can be implemented by means of finite state automata. Computing type matching then is equivalent to check if a given sequence of items is recognized by its corresponding finite state automata. Finite state automata and their relationships to regular expressions have been extensively studied and documented in computer-science literature. The interested reader can consult the relevant literature, for instance [Languages], or [TATA].
Introduction
This section defines the semantics of subtyping in [XPath/XQuery]. Subtyping is used during static type analysis, in typeswitch, treat and assert expressions, and to check the correctness of function applications.
Note that intuitive relationships between types. For instance, that (Type,()) is equivalent to Type can be deduced using the subtyping judgment (and algorithm) described here.
Notation
The judgment
holds if the first type is a subtype of the second.
Semantics
This judgment is true if and only if, for every value Value, if Value matches Type1 holds, then Value matches Type2 also holds.
Note
It is easy to see that the subtype relation <: is a partial order, i.e. it is reflexive:
statEnv |- Type <: Typeand it is transitive: if,
statEnv |- Type1 <: Type2and,
statEnv |- Type2 <: Type3then,
statEnv |- Type1 <: Type3Finally, two types are equal if each is a subtype of the other, that is:
statEnv |- Type1 <: Type2and,
statEnv |- Type2 <: Type1then,
statEnv |- Type1 = Type2Note
The above definition, although complete and precise, does not give a simple means to compute subtyping. Notably the definition above refers to values, which are not available at static type checking time.
The structural component of the [XPath/XQuery] type system can be modeled by regular expressions. Regular expressions can be implemented by means of finite state automata. Computing subtyping between two types can then be done by computing if inclusion holds between their corresponding finite state automata.
Finite state automata and how to compute operations on those automata, such as inclusion, emptiness or intersection, have been extensively studied and documented in the literature. The interested reader can consult the relevant literature on tree grammars, for instance [Languages], or [TATA].
Introduction
Some [XPath/XQuery] operations work on sequences of items. For
instance, [For/FLWOR] expressions iterate over a sequence of items
and the fn:unordered
function can return all items in
a sequence in any order, etc.
Static typing for those operations needs to infer a type acceptable for all the items in the sequence. This sometimes requires approximating the type known for each item individually.
Example
Assume the variable $shipTo
is bound to the shipTo
element
<shipTo country="US"> <name>Alice Smith</name> <street>123 Maple Street</street> <city>Mill Valley</city> <state>CA</state> <zip>90952</zip> </shipTo>
and has type
element shipTo of type USAddress
The following query orders all children of the shipTo element by alphabetical order of their content.
for $x in $shipTo/* order by $x/text() return $x
resulting in the sequence
(<street>123 Maple Street</street>, <zip>90952</zip>, <name>Alice Smith</name>, <state>CA</state>, <city>Mill Valley</city>)
This operation iterates over the elements in the input sequence
returned by the expression $shipTo/*
, whose type is
the content of a type USAddress.
(element name of type xsd:string, element street of type xsd:string, element city of type xsd:string, element state of type xsd:string, element zip of type xsd:decimal)
During static typing, one must give a type to the variable
$x
which corresponds to the type of each element in
the sequence. Since each item is of a different type, one must find
an item type which is valid for all cases in the sequence. This can
be done by using a choice for the variable $x
, as
follows
(element name of type xsd:string | element street of type xsd:string | element city of type xsd:string | element state of type xsd:string | element zip of type xsd:decimal)
This type indicates that the type of the variable can be of any of the item types in the input sequence.
The static inference also needs to approximate the number of
occurrences of items in the sequence. In this example, there is at
least one item and more than one, so the closest occurrence
indicator is +
for one or more items.
The static inference for this example finally results in the following type.
(element name of type xsd:string | element street of type xsd:string | element city of type xsd:string | element state of type xsd:string | element zip of type xsd:decimal)+
[Definition: A prime type is a choice of item types.] This section defines two functions on types that compute the prime type of an arbitrary type, and approximate the occurrence of items in an arbitrary type. These type functions are used in the static semantics of many expressions, including "for", "some", and "every" expressions, and many functions, including "fn:unordered" and "fn:distinct-values".
Notation
A choice of item types is called a prime type, as described by the following grammar production.
| [44 (Formal)] | PrimeType |
::= | FormalItemType |
Notation
The type function prime(Type) extracts all item types from the type Type, and combines them into a choice.
The function quantifier(Type)
approximates the possible number of items in Type with the occurrence indicators
supported by the [XPath/XQuery] type system (?, +,
*
).
For interim results, the auxiliary occurrence indicator
1
denotes exactly one occurrence.
Semantics
The prime function is defined by induction as follows.
| prime(FormalItemType) | = | FormalItemType |
prime(empty ) |
= | none |
prime(none ) |
= | none |
| prime(Type1 , Type2) | = | prime(Type1) | prime(Type2) |
| prime(Type1 & Type2) | = | prime(Type1) | prime(Type2) |
| prime(Type1 | Type2) | = | prime(Type1) | prime(Type2) |
| prime(Type?) | = | prime(Type) |
| prime(Type*) | = | prime(Type) |
| prime(Type+) | = | prime(Type) |
Note
This function is typically used in judgments of the form:
In cases where prime(Type) =
none
, there may be a temptation to bind FormalItemType1
to none
and n
to 1
. However,
it is important to note that none
is not a FormalItemType, rather it is
equivalent to a union type with no member types. Thus, in such
cases, the proper way to satisfy the given judgment is to bind
n
to 0
.
Semantics
The quantifier function is defined by induction as follows.
| quantifier(FormalItemType) | = | 1 |
quantifier(empty ) |
= | ? |
quantifier(none ) |
= | 1 |
| quantifier(Type1 , Type2) | = | quantifier(Type1) , quantifier(Type2) |
| quantifier(Type1 & Type2) | = | quantifier(Type1) , quantifier(Type2) |
| quantifier(Type1 | Type2) | = | quantifier(Type1) | quantifier(Type2) |
| quantifier(Type?) | = | quantifier(Type) · ? |
| quantifier(Type*) | = | quantifier(Type) · * |
| quantifier(Type+) | = | quantifier(Type) · + |
This definition uses the sum (OccurrenceIndicator1 , OccurrenceIndicator2), the choice (OccurrenceIndicator1 | OccurrenceIndicator2), and the product (OccurrenceIndicator1 · OccurrenceIndicator2) of two occurrence indicators OccurrenceIndicator1, OccurrenceIndicator2, which are defined by the following tables.
|
|
|
Examples
For example, here are the result of applying prime and quantifier on a few simple types.
prime(element a+) = element a prime(element a | empty) = element a prime(element a?,element b?) = element a | element b prime(element a | element b+, element c*) = element a | element b | element c quantifier(element a+) = + quantifier(element a | empty) = ? quantifier(element a?,element b?) = * quantifier(element a | element b+, element d*) = +
Note that the last occurrence indicator should be '+', since the regular expression is such that there must be at least one element in the sequence (this element being an 'a' element or a 'b' element).
Note
Note that prime(Type) · quantifier(Type) is always a super type of the original type Type I.e., Type <: prime(Type) · quantifier(Type) always holds. Therefore, it is appropriate to used it as an approximation for the type of an expression. This property is required for the soundness of the static type analysis.
Semantics
Finally, a type Type and an occurrence indicator can be combined back together to yield a new type with the · operation, as follows.
| Type · 1 | = | Type |
| Type · ? | = | Type? |
| Type · + | = | Type+ |
| Type · * | = | Type* |
Introduction
Function calls can perform type promotion between atomic types.
This section introduces judgments which describe type promotion for
the purpose of the dynamic and static semantics. These promotion
rules include promoting xs:untypedAtomic
to any
other type.
Notation
The judgment
holds if type Type1 can be promoted to type Type2.
Example
For example, the following judgments hold:
xs:integer can be promoted to xs:integer xs:decimal can be promoted to xs:float xs:integer can be promoted to xs:float xs:float can be promoted to xs:double
Semantics
This judgment is specified by the following rules.
xs:decimal
can be promoted to
xs:float
:
|
|
||
|
xs:float
can be promoted to
xs:double
:
|
|
||
|
xs:anyURI
can be promoted to
xs:string
:
|
|
||
|
xs:untypedAtomic
can be promoted to any atomic type:
A type can be promoted to itself or to any type of which it is a subtype:
Type promotion is transitive:
| statEnv |- Type1 can be promoted to Type2 statEnv |- Type2 can be promoted to Type3 | ||
|
|
||
|
Finally, type promotion distributes over occurrence and union constructors.
| statEnv |- prime(Type1) can be promoted to prime(Type2) quantifier(Type1) <= quantifier(Type2) | ||
|
|
||
|
| statEnv |- Type1 can be promoted to Type statEnv |- Type2 can be promoted to Type | ||
|
|
||
|
where the "<=" operator for occurrence indicators denotes set inclusion of the subsets of the allowed occurrences.
Notation
The judgment
holds if value Value1 can be promoted to the value Value2 against the type Type2.
Example
For example, the following judgments hold
1 of type xs:integer against xs:integer promotes to 1 of type xs:integer 1 of type xs:integer against xs:decimal promotes to 1 of type xs:integer 1 of type xs:integer against xs:float promotes to 1.0e0 of type xs:float 1.0e0 of type xs:float against xs:double promotes to 1.0e0 of type xs:double
Note that type promotion changes the value, and only occurs if the input value does not match the target type.
Semantics
This judgment is specified by the following rules.
If the value matches the target type, then it is promoted to itself
If the value does not match the target type, but is an atomic value and it matches a type which can be promoted to the target type, then the value is cast to the target type.
Notation
A validation mode may occur explicitly in a validate expression [4.13 Validate Expressions]. The following with mode judgment resolves an element name within a given validation mode to the type that the element name denotes. The judgment is used in the semantics of the validate expression and in sequence type.
The judgment
holds when the possibly optional element name resolves to the given type in the given validation mode.
Semantics
We start with the rules for the global validation context.
If no element name is present, the global validation context resolves to the union of all element types that are globally declared.
|
|||||||
|
|
|||||||
| statEnv |- * with mode ValidationMode resolves to (element ElementName1 | ... | element ElementNamen) |
If the element name is globally declared in the schema, it resolves to the element type of the corresponding global element declaration, independently of the validation mode.
|
|||
|
|
|||
| statEnv |- ElementName with mode ValidationMode resolves to element ElementName |
If an element name is not globally defined and the validation mode is lax, then the element name resolves to the element type with the given element name with any content type.
|
|||
|
|
|||
statEnv |- ElementName with mode
lax resolves to element ElementName of type
xs:anyType |
This section contains the set of productions for the of [XPath/XQuery] grammar after it has been normalized, sometimes referred to as the "core" grammar, and for the formal grammar productions.
The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.
| [99] | IntegerLiteral |
::= | Digits |
| [100] | DecimalLiteral |
::= | ("." Digits) | (Digits "." [0-9]*) |
| [101] | DoubleLiteral |
::= | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits |
| [102] | StringLiteral |
::= | ('"' (EscapeQuot |
[^"])* '"') | ("'" (EscapeApos
| [^'])* "'") |
| [103] | EscapeQuot |
::= | '""' |
| [104] | EscapeApos |
::= | "''" |
| [105] | ElementContentChar |
::= | Char -
[{}<&] |
| [106] | QuotAttrContentChar |
::= | Char -
["{}<&] |
| [107] | AposAttrContentChar |
::= | Char -
['{}<&] |
| [108] | PITarget |
::= | [http://www.w3.org/TR/REC-xml#NT-PITarget]XML |
| [109] | QName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-QName]Names |
| [110] | NCName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-NCName]Names |
| [111] | S |
::= | [http://www.w3.org/TR/REC-xml#NT-S]XML |
| [112] | Char |
::= | [http://www.w3.org/TR/REC-xml#NT-Char]XML |
| [1] | ModuleDecl |
::= | "module" "namespace" NCName "=" URILiteral Separator |
| [2] | Separator |
::= | ";" |
| [3] | NamespaceDecl |
::= | "declare" "namespace" NCName "=" URILiteral |
| [4] | DefaultNamespaceDecl |
::= | "declare" "default" ("element" | "function") "namespace"
URILiteral |
| [5] | OptionDecl |
::= | "declare" "option" QName
StringLiteral |
| [6] | OrderingModeDecl |
::= | "declare" "ordering" ("ordered" |
"unordered") |
| [7] | EmptyOrderDecl |
::= | "declare" "default" "order" "empty" ("greatest" |
"least") |
| [8] | CopyNamespacesDecl |
::= | "declare" "copy-namespaces" PreserveMode "," InheritMode |
| [9] | PreserveMode |
::= | "preserve" | "no-preserve" |
| [10] | InheritMode |
::= | "inherit" | "no-inherit" |
| [11] | DefaultCollationDecl |
::= | "declare" "default" "collation" URILiteral |
| [12] | BaseURIDecl |
::= | "declare" "base-uri" URILiteral |
| [13] | SchemaImport |
::= | "import" "schema" SchemaPrefix? URILiteral ("at" URILiteral ("," URILiteral)*)? |
| [14] | SchemaPrefix |
::= | ("namespace" NCName "=")
| ("default" "element" "namespace") |
| [15] | ModuleImport |
::= | "import" "module" ("namespace" NCName "=")? URILiteral ("at" URILiteral ("," URILiteral)*)? |
| [16] | VarDecl |
::= | "declare" "variable" "$" QName TypeDeclaration? ((":=" ExprSingle) | "external") |
| [17] | ConstructionDecl |
::= | "declare" "construction" ("strip" |
"preserve") |
| [18] | FunctionDecl |
::= | "declare" "function" QName
"(" ParamList? ")" ("as"
SequenceType)? (EnclosedExpr |
"external") |
| [19] | ParamList |
::= | Param ("," Param)* |
| [20] | Param |
::= | "$" QName TypeDeclaration? |
| [21] | EnclosedExpr |
::= | "{" Expr "}" |
| [22] | Expr |
::= | ExprSingle (","
ExprSingle)* |
| [23] | ExprSingle |
::= | FLWORExpr |
| [24] | FLWORExpr |
::= | (ForClause | LetClause) "return" ExprSingle |
| [25] | ForClause |
::= | "for" "$" VarName
TypeDeclaration? PositionalVar? "in" ExprSingle |
| [26] | PositionalVar |
::= | "at" "$" VarName |
| [27] | LetClause |
::= | "let" "$" VarName
TypeDeclaration? ":="
ExprSingle |
| [28] | OrderByClause |
::= | (("order" "by") | ("stable" "order" "by")) OrderSpecList |
| [29] | OrderSpecList |
::= | OrderSpec (","
OrderSpec)* |
| [30] | OrderSpec |
::= | ExprSingle OrderModifier |
| [31] | OrderModifier |
::= | ("ascending" | "descending")? ("empty" ("greatest" |
"least"))? ("collation" URILiteral)? |
| [32] | QuantifiedExpr |
::= | ("some" | "every") "$" VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle |
| [33] | TypeswitchExpr |
::= | "typeswitch" "(" Expr ")"
CaseClause+ "default" "$"
VarName "return" ExprSingle |
| [34] | CaseClause |
::= | "case" "$" VarName "as"
SequenceType "return"
ExprSingle |
| [35] | IfExpr |
::= | "if" "(" Expr ")" "then"
ExprSingle "else" ExprSingle |
| [36] | OrExpr |
::= | AndExpr ( "or" AndExpr )* |
| [37] | AndExpr |
::= | CastableExpr (
"and" CastableExpr
)* |
| [38] | CastableExpr |
::= | CastExpr ( "castable"
"as" SingleType )? |
| [39] | CastExpr |
::= | ValueExpr ( "cast"
"as" SingleType )? |
| [40] | ValueExpr |
::= | ValidateExpr |
StepExpr | ExtensionExpr |
| [41] | ValidateExpr |
::= | "validate" ValidationMode? "{" Expr "}" |
| [42] | ValidationMode |
::= | "lax" | "strict" |
| [43] | ExtensionExpr |
::= | Pragma+ "{" Expr? "}" |
| [44] | Pragma |
::= | "(#" S? QName (S PragmaContents)? "#)" |
| [45] | PragmaContents |
::= | (Char* - (Char* '#)'
Char*)) |
| [46] | StepExpr |
::= | PrimaryExpr |
AxisStep |
| [47] | AxisStep |
::= | ReverseStep |
ForwardStep |
| [48] | ForwardStep |
::= | ForwardAxis NodeTest |
| [49] | ForwardAxis |
::= | ("child" "::") |
| [50] | ReverseStep |
::= | ReverseAxis NodeTest |
| [51] | ReverseAxis |
::= | ("parent" "::") |
| [52] | NodeTest |
::= | KindTest | NameTest |
| [53] | NameTest |
::= | QName | Wildcard |
| [54] | Wildcard |
::= | "*" |
| [55] | PrimaryExpr |
::= | Literal | VarRef | ParenthesizedExpr | FunctionCall | OrderedExpr | UnorderedExpr | Constructor |
| [56] | Literal |
::= | NumericLiteral |
StringLiteral |
| [57] | NumericLiteral |
::= | IntegerLiteral |
DecimalLiteral | DoubleLiteral |
| [58] | VarRef |
::= | "$" VarName |
| [59] | VarName |
::= | QName |
| [60] | ParenthesizedExpr |
::= | "(" Expr? ")" |
| [61] | OrderedExpr |
::= | "ordered" "{" Expr
"}" |
| [62] | UnorderedExpr |
::= | "unordered" "{" Expr
"}" |
| [63] | FunctionCall |
::= | QName "(" (ExprSingle ("," ExprSingle)*)? ")" |
| [64] | Constructor |
::= | ComputedConstructor |
| [65] | ComputedConstructor |
::= | CompDocConstructor |
| [66] | CompDocConstructor |
::= | "document" "{" Expr
"}" |
| [67] | CompElemConstructor |
::= | "element" (QName | ("{"
Expr "}")) "{" ContentExpr "}" "{" LocalNamespaceDecls
"}" |
| [68] | LocalNamespaceDecl |
::= | "namespace" NCName "{"
URILiteral "}" |
| [69] | ContentExpr |
::= | Expr |
| [70] | CompAttrConstructor |
::= | "attribute" (QName | ("{"
Expr "}")) "{" Expr "}" |
| [71] | CompTextConstructor |
::= | "text" "{" Expr
"}" |
| [72] | CompCommentConstructor |
::= | "comment" "{" Expr
"}" |
| [73] | CompPIConstructor |
::= | "processing-instruction" (NCName | ("{" Expr "}")) "{" Expr? "}" |
| [74] | SingleType |
::= | AtomicType
"?"? |
| [75] | TypeDeclaration |
::= | "as" SequenceType |
| [76] | SequenceType |
::= | ("empty-sequence" "(" ")") |
| [77] | OccurrenceIndicator |
::= | "?" | "*" | "+" |
| [78] | ItemType |
::= | KindTest | ("item" "("
")") | AtomicType |
| [79] | AtomicType |
::= | QName |
| [80] | KindTest |
::= | DocumentTest |
| [81] | AnyKindTest |
::= | "node" "(" ")" |
| [82] | DocumentTest |
::= | "document-node" "(" (ElementTest | SchemaElementTest)?
")" |
| [83] | TextTest |
::= | "text" "(" ")" |
| [84] | CommentTest |
::= | "comment" "(" ")" |
| [85] | PITest |
::= | "processing-instruction" "(" (NCName | StringLiteral)? ")" |
| [86] | AttributeTest |
::= | "attribute" "(" (AttribNameOrWildcard (","
TypeName)?)? ")" |
| [87] | AttribNameOrWildcard |
::= | AttributeName |
"*" |
| [88] | SchemaAttributeTest |
::= | "schema-attribute" "(" AttributeDeclaration
")" |
| [89] | AttributeDeclaration |
::= | AttributeName |
| [90] | ElementTest |
::= | "element" "(" (ElementNameOrWildcard (","
TypeName "?"?)?)? ")" |
| [91] | ElementNameOrWildcard |
::= | ElementName |
"*" |
| [92] | SchemaElementTest |
::= | "schema-element" "(" ElementDeclaration
")" |
| [93] | ElementDeclaration |
::= | ElementName |
| [94] | AttributeName |
::= | QName |
| [95] | ElementName |
::= | QName |
| [96] | TypeName |
::= | QName |
| [97] | URILiteral |
::= | StringLiteral |
| [98] | LocalNamespaceDecls |
::= | LocalNamespaceDecl* |
| [113] | Digits |
::= | [0-9]+ |
The following grammar uses the same Basic EBNF notation as [XML], except that grammar symbols always have initial capital letters. The EBNF contains the lexemes embedded in the productions.
| [96] | HexDigits |
::= | [0-9a-fA-F]+ |
| [97] | CharRef |
::= | "&#" (Digits | ("x"
HexDigits)) ";" |
| [98] | Char |
::= | #x0009#x000D#x000A#x0020-#xFFFD |
| [1] | AtomicValueContent |
::= | String |
| [2] | TypeAnnotation |
::= | "of" "type" TypeName |
| [3] | ElementName |
::= | QName |
| [4] | ElementNameOrWildcard |
::= | QName | "*" |
| [5] | AttributeNameOrWildcard |
::= | QName | "*" |
| [6] | AttributeName |
::= | QName |
| [7] | Value |
::= | Item |
| [8] | SimpleValue |
::= | AtomicValue |
| [9] | ElementValue |
::= | "element" ElementName
"nilled"? TypeAnnotation? "{"
Value "}" ("{" NamespaceBindings
"}")? |
| [10] | AttributeValue |
::= | "attribute" AttributeName TypeAnnotation? "{" SimpleValue "}" |
| [11] | DocumentValue |
::= | "document" "{" Value
"}" |
| [12] | TextValue |
::= | "text" "{" String "}" |
| [13] | CommentValue |
::= | "comment" "{" String "}" |
| [14] | ProcessingInstructionValue |
::= | "processing-instruction" NCName "{" String "}" |
| [15] | NamespaceBindings |
::= | NamespaceBinding
("," NamespaceBinding)* |
| [16] | LocationHints |
::= | "at" URILiteral (","
URILiteral)* |
| [17] | NamespaceBinding |
::= | "namespace" NCName "{"
AnyURI "}" |
| [18] | Prefix |
::= | NCName |
| [19] | LocalPart |
::= | NCName |
| [20] | NodeValue |
::= | ElementValue |
| [21] | Item |
::= | NodeValue |
| [22] | AtomicValue |
::= | AtomicValueContent TypeAnnotation? |
| [23] | TypeName |
::= | QName |
| [24] | Type |
::= | FormalItemType |
| [25] | FormalItemType |
::= | AtomicTypeName |
NodeType |
| [26] | NodeType |
::= | DocumentType |
| [27] | ElementContentType |
::= | ElementType |
| [28] | AtomicTypeName |
::= | TypeName |
| [29] | ElementType |
::= | "element" ElementNameOrWildcard OptTypeSpecifier |
| [30] | TypeSpecifier |
::= | OptNillable TypeReference |
| [31] | AttributeType |
::= | "attribute" AttributeNameOrWildcard
OptTypeReference |
| [32] | Nillable |
::= | "nillable" |
| [33] | TypeDerivation |
::= | ComplexTypeDerivation |
AtomicTypeDerivation |
| [34] | ComplexTypeDerivation |
::= | OptDerivation
OptMixed "{" Type? "}" |
| [35] | AtomicTypeDerivation |
::= | "restricts" AtomicTypeName |
| [36] | TypeReference |
::= | "of" "type" TypeName |
| [37] | Derivation |
::= | ("restricts" TypeName) |
| [38] | Mixed |
::= | "mixed" |
| [39] | Definition |
::= | ("define" "element" ElementName OptSubstitution OptNillable TypeReference) |
| [40] | Definitions |
::= | (Definition Separator Definitions)? |
| [41] | Substitution |
::= | "substitutes" "for" ElementName |
| [42] | AttributeModel |
::= | AttributeType |
| [43] | ElementModel |
::= | ElementType |
| [44] | PrimeType |
::= | FormalItemType |
| [45] | DocumentType |
::= | "document" ("{" Type
"}")? |
| [46] | SPragma |
::= | ("include" | "import" | "redefine" |
"annotation")* |
| [47] | Content |
::= | (("simpleType" | "complexType" | "element" | "attribute"
| "attributeGroup" | "group" | "notation")
"annotation"*)* |
| [48] | MixedAttribute |
::= | "mixed" "=" Boolean |
| [49] | NillableAttribute |
::= | "nillable" "=" Boolean |
| [50] | substitutionGroupAttribute |
::= | "substitutionGroup" "=" QName |
| [51] | maxLength |
::= | "maxLength" "=" "nonNegativeInteger" |
| [52] | minLength |
::= | "minLength" "=" "nonNegativeInteger" |
| [53] | length |
::= | "length" "=" "nonNegativeInteger" |
| [54] | maxOccurs |
::= | "maxOccurs" "=" ("nonNegativeInteger" |
"unbounded") |
| [55] | minOccurs |
::= | "minOccurs" "=" "nonNegativeInteger" |
| [56] | OccursAttributes |
::= | maxOccurs | minOccurs | maxLength | minLength | length |
| [57] | ComplexTypeContent |
::= | "annotation"? ("simpleContent" | "complexContent" |
(ChildrenContent AttributeContent)) |
| [58] | ChildrenContent |
::= | ("group" | "all" | "choice" | "sequence")? |
| [59] | GroupComponent |
::= | "element" | "group" | "choice" | "sequence" |
"any" |
| [60] | AttributeContent |
::= | ("attribute" | "attributeGroup")*
"anyAttribute"? |
| [61] | UseAttribute |
::= | "use" "=" ("optional" | "prohibited" |
"required") |
| [62] | DefaultAttribute |
::= | "default" "=" String |
| [63] | FixedAttribute |
::= | "fixed" "=" String |
| [64] | PrincipalNodeKind |
::= | "element" | "attribute" | "namespace" |
| [65] | FormalFLWORClause |
::= | ForClause | LetClause | WhereClause | OrderByClause |
| [66] | FormalReturnClause |
::= | FormalFLWORExpr |
("return" Expr) |
| [67] | FormalFLWORExpr |
::= | FormalFLWORClause FormalReturnClause |
| [68] | FormalCaseClauses |
::= | (FormalCaseClause
FormalCaseClauses) |
FormalDefaultCaseClause |
| [69] | FormalCaseClause |
::= | "case" "$" VarName "as"
SequenceType "return" Expr |
| [70] | FormalDefaultCaseClause |
::= | "default" "$" VarName
"return" Expr |
| [71] | PrologDeclList |
::= | (PrologDecl Separator PrologDeclList)? |
| [72] | PrologDecl |
::= | DefaultCollationDecl |
| [73] | OptAtomicType |
::= | AtomicTypeName |
(AtomicTypeName "?") |
"empty" |
| [74] | OptMixed |
::= | Mixed? |
| [75] | OptNillable |
::= | Nillable? |
| [76] | OptSubstitution |
::= | Substitution? |
| [77] | OptTypeSpecifier |
::= | TypeSpecifier? |
| [78] | OptTypeReference |
::= | TypeReference? |
| [79] | OptTypeDeclaration |
::= | TypeDeclaration? |
| [80] | OptPositionalVar |
::= | PositionalVar? |
| [81] | OptVarName |
::= | ("$" VarName)? |
| [82] | OptLocationHints |
::= | LocationHints? |
| [83] | ElementContentUnit |
::= | DirectConstructor | EnclosedExpr | DirCharsUnit |
| [84] | DirCharsUnit |
::= | (CDataSection |
PredefinedEntityRef |
CharRef | "{{" | "}}" | ElementContentChar)+ |
| [85] | FunctionSig |
::= | "declare" "function" expanded-QName "(" TypeList? ")" "as" Type |
| [86] | TypeList |
::= | Type ("," Type)* |
| [87] | AttributeContentUnits |
::= | AttributeContentUnit* |
| [88] | AttributeContentUnit |
::= | AttributeCharsUnit | EnclosedExpr |
| [89] | ConstructionMode |
::= | "preserve" | "strip" |
| [90] | Axis |
::= | ForwardAxis |
ReverseAxis |
| [91] | AttributeCharsUnit |
::= | (QuotAttrContentChar |
AposAttrContentChar |
EscapeQuot | EscapeApos | PredefinedEntityRef |
CharRef | "{{" |
"}}")+ |
| [92] | FunctionKey |
::= | expanded-QName "," Arity |
| [93] | ProcessingInstructionType |
::= | "processing-instruction" PITargetOrWildcard |
| [94] | PITargetOrWildcard |
::= | NCName | "*" |
| [95] | OptDerivation |
::= | Derivation? |
Here is the list of the judgments defined in this specification.
Main judgments:
Auxiliary judgments:
statEnv |- (AnyURI | #MAIN) =>module_statEnv statEnv
statEnv |- (AnyURI | #MAIN) =>module_dynEnv dynEnv
statEnv1 |- PrologDeclList =>stat statEnv2 with PrologDeclList1
dynEnv1 ; AnyURI |- (FunctionKey1,FunctionSig1) ... (FunctionKeyn,FunctionSign) =>import_functions dynEnv2
dynEnv1 ; AnyURI |- (expanded-QName1, Type1), ···, (expanded-QNamen, Typen) =>import_variables dynEnv2
statEnv |- OptMixed Type1 adjusts to Type2
dynEnv |- Value can be cast to SingleType
dynEnv1 extended with dynamic environment dynEnv2 yields dynEnv3 for uri AnyURI
statEnv1 extended with static environment statEnv2 yields statEnv3 for uri AnyURI
statEnv |- function declaration FunctionDecl with signature FunctionSig : Typer
dynEnv |- function expanded-QName with types (Type1,...,Typen) on values (Value1,...,Valuen) yields Value
dynEnv |- LiteralExpr has atomic value AtomicValue
statEnv |- Type1 has node content Type2
Axis has principal PrincipalNodeKind
AnyURI is target namespace of modules Module1 ... Modulen
statEnv |- ElementName name lookup ElementType yields OptNillable TypeReference
statEnv |- AttributeName name lookup AttributeType yields TypeReference
statEnv |- nil-annotate as Nillable? Type ( Value1 ) => Value2
statEnv |- QName of attr expands to expanded-QName
statEnv |- QName of elem/type expands to expanded-QName
statEnv |- QName of func expands to expanded-QName
statEnv |- QName of var expands to Variable
expanded-QName operator type for AtomicType1 and AtomicType2 is AtomicType3
statEnv |- OptMixed Type1 opt-mixes to Type2
statEnv |- TypeReference resolves to TypeName { Type }
second argument contribution for sum with Type1 and Type2 is Type3
statEnv |- simply annotate as SimpleType ( SimpleValue ) => SimpleValue2
statEnv |- SimpleValue simply erases to String
statEnv |- ElementType type lookup OptNillable TypeReference
statEnv |- test NodeTest with PrincipalNodeKind of Type1 : Type2
dynEnv |- test NodeTest with PrincipalNodeKind of Value1 => Value2
statEnv |- type definitions derived from TypeName are Definition1 ... Definitionn
statEnv |- ElementNameOrWildcard with mode ValidationMode resolves to Type
Here is the list of functions from the [XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)] document that are used in the [XPath/XQuery] Formal Semantics:
This section gives the semantics specific to overloaded internal functions (with prefix fs:) that are used to define overloaded XQuery operators (with prefix op:), such as comparison expressions or arithmetic expressions. Static typing for those functions are defined over unions of (possibly optional) atomic types. The semantics is obtained in three steps. First, a rule is applied to deal with the union of those (possibly optional) atomic types. A second set of rules treat the cases where one of the operands of those functions is the empty type (resp. empty sequence) or optional. Finally, a final rule deals with type promotion and access to an operators mapping table which maps the overloaded internal functions to the appropriate operator functions defined in [XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)] and give the corresponding type.
Notation
The following auxiliary grammar production describe optional atomic types.
| [73 (Formal)] | OptAtomicType |
::= | AtomicTypeName |
(AtomicTypeName "?") |
"empty" |
The following static typing rules apply generically to all the fs: special functions. They do not apply to any other function calls, which are treated in [4.1.5 Function Calls].
First, if the static type of one or several of the expressions passed as argument is a union of atomic types, the function call is type checked once separately for each atomic type in that union. The static type of the entire function call expression is then the union of the types computed in each case.
|
|||||||
|
|
|||||||
|
Note
Note that this approach can be used since the type declared for a function parameter is never itself be a union.
The following rules deal with optional arguments. In the case of binary operators, if either one of the types of the operands is empty, the resulting type is empty.
If either one of the types of the operands is optional, the type obtained by propagating the optional occurrence indicator.
|
||||
|
|
||||
| statEnv |- expanded-QName(Type1,Type2) : AtomicType3? |
|
||||
|
|
||||
| statEnv |- expanded-QName(Type1,Type2) : AtomicType3? |
|
||||
|
|
||||
| statEnv |- expanded-QName(Type1,Type2) : AtomicType3? |
In the case of unary operators, if the type of the operand is empty, the resulting type is empty.
|
||
|
|
||
| statEnv |- expanded-QName(Type1) : empty |
Finally, the resulting type is obtained by performing type promotion and accessing the operators mapping table (using the operator type for judgment defined below).
|
||||
|
|
||||
|
|
|||
|
|
|||
|
Each fs:
overloaded operator maps to the
corresponding equivalent overloaded op:
operator, as
defined in [XQuery 1.0 and XPath 2.0
Functions and Operators (Second Edition)], and deals with the
case where one of the operands is the empty sequence.
The dynamic semantics of the fs:
operator is
similar to using the following user-defined function.
declare function fs:opname($x1 as
xs:anyAtomicType?, $x2 as xs:anyAtomicType?) as xs:anyAtomicType?
{ |
if (fn:empty($x1) or fn:empty($x2)) then ()
else [fs:opname($x1,$x2)]OverloadedOp |
}; |
Where [fs:opname()]OverloadedOp maps to the corresponding op: operator in [XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)], as defined in the table below.
Notation
The operators mapping table is given below. The table is used to define the following auxiliary mapping rules and judgments.
The mapping rule for binary and unary operators
and
where the operator depends on the type of each value returned by Expr1 and Expr2.
The judgments for binary and unary operators
and
hold when the operator table indicates that the operator expanded-QName has the output type AtomicType3 for the input types AtomicType1 and AtomicType2.
Note that in the following table, all numeric functions are applied to operands with the same type. Values are promoted to compatible types using the function call semantics given in [4.1.5 Function Calls].
Gregorian refers to the types xs:gYearMonth
,
xs:gYear
, xs:gMonthDay
,
xs:gDay
, and xs:gMonth
. For binary
operators that accept two Gregorian-type operands, both operands
must have the same type (for example, if one operand is of type
xs:gDay
, the other operand must be of type
xs:gDay
.)
| Internal Function | AtomicType1 | AtomicType2 | Denotes | AtomicType3 |
|---|---|---|---|---|
fs:plus (A, B) |
xs:integer |
xs:integer |
op:numeric-add(A, B) | xs:integer |
fs:plus (A, B) |
xs:decimal |
xs:decimal |
op:numeric-add(A, B) | xs:decimal |
fs:plus (A, B) |
xs:float |
xs:float |
op:numeric-add(A, B) | xs:float |
fs:plus (A, B) |
xs:double |
xs:double |
op:numeric-add(A, B) | xs:double |
fs:plus (A, B) |
xs:date |
xs:yearMonthDuration |
op:add-yearMonthDuration-to-date(A, B) | xs:date |
fs:plus (A, B) |
xs:yearMonthDuration |
xs:date |
op:add-yearMonthDuration-to-date(B, A) | xs:date |
fs:plus (A, B) |
xs:date |
xs:dayTimeDuration |
op:add-dayTimeDuration-to-date(A, B) | xs:date |
fs:plus (A, B) |
xs:dayTimeDuration |
xs:date |
op:add-dayTimeDuration-to-date(B, A) | xs:date |
fs:plus (A, B) |
xs:time |
xs:dayTimeDuration |
op:add-dayTimeDuration-to-time(A, B) | xs:time |
fs:plus (A, B) |
xs:dayTimeDuration |
xs:time |
op:add-dayTimeDuration-to-time(B, A) | xs:time |
fs:plus (A, B) |
xs:dateTime |
xs:yearMonthDuration |
op:add-yearMonthDuration-to-dateTime(A, B) | xs:dateTime |
fs:plus (A, B) |
xs:yearMonthDuration |
xs:dateTime |
op:add-yearMonthDuration-to-dateTime(B, A) | xs:dateTime |
fs:plus (A, B) |
xs:dateTime |
xs:dayTimeDuration |
op:add-dayTimeDuration-to-dateTime(A, B) | xs:dateTime |
fs:plus (A, B) |
xs:dayTimeDuration |
xs:dateTime |
op:add-dayTimeDuration-to-dateTime(B, A) | xs:dateTime |
fs:plus (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:add-yearMonthDurations(A, B) | xs:yearMonthDuration |
fs:plus (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:add-dayTimeDurations(A, B) | xs:dayTimeDuration |
fs:minus (A, B) |
xs:integer |
xs:integer |
op:numeric-subtract(A, B) | xs:integer |
fs:minus (A, B) |
xs:decimal |
xs:decimal |
op:numeric-subtract(A, B) | xs:decimal |
fs:minus (A, B) |
xs:float |
xs:float |
op:numeric-subtract(A, B) | xs:float |
fs:minus (A, B) |
xs:double |
xs:double |
op:numeric-subtract(A, B) | xs:double |
fs:minus (A, B) |
xs:date |
xs:date |
op:subtract-dates(A, B) | xs:dayTimeDuration |
fs:minus (A, B) |
xs:date |
xs:yearMonthDuration |
op:subtract-yearMonthDuration-from-date(A, B) | xs:date |
fs:minus (A, B) |
xs:date |
xs:dayTimeDuration |
op:subtract-dayTimeDuration-from-date(A, B) | xs:date |
fs:minus (A, B) |
xs:time |
xs:time |
op:subtract-times(A, B) | xs:dayTimeDuration |
fs:minus (A, B) |
xs:time |
xs:dayTimeDuration |
op:subtract-dayTimeDuration-from-time(A, B) | xs:time |
fs:minus (A, B) |
xs:dateTime |
xs:dateTime |
op:subtract-dateTimes(A, B) | xs:dayTimeDuration |
fs:minus (A, B) |
xs:dateTime |
xs:yearMonthDuration |
op:subtract-yearMonthDuration-from-dateTime(A, B) | xs:dateTime |
fs:minus (A, B) |
xs:dateTime |
xs:dayTimeDuration |
op:subtract-dayTimeDuration-from-dateTime(A, B) | xs:dateTime |
fs:minus (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:subtract-yearMonthDurations(A, B) | xs:yearMonthDuration |
fs:minus (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:subtract-dayTimeDurations(A, B) | xs:dayTimeDuration |
fs:times (A, B) |
xs:integer |
xs:integer |
op:numeric-multiply(A, B) | xs:integer |
fs:times (A, B) |
xs:decimal |
xs:decimal |
op:numeric-multiply(A, B) | xs:decimal |
fs:times (A, B) |
xs:float |
xs:float |
op:numeric-multiply(A, B) | xs:float |
fs:times (A, B) |
xs:double |
xs:double |
op:numeric-multiply(A, B) | xs:double |
fs:times (A, B) |
xs:yearMonthDuration |
xs:double |
op:multiply-yearMonthDuration(A, B) | xs:yearMonthDuration |
fs:times (A, B) |
xs:double |
xs:yearMonthDuration |
op:multiply-yearMonthDuration(B, A) | xs:yearMonthDuration |
fs:times (A, B) |
xs:dayTimeDuration |
xs:double |
op:multiply-dayTimeDuration(A, B) | xs:dayTimeDuration |
fs:times (A, B) |
xs:double |
xs:dayTimeDuration |
op:multiply-dayTimeDuration(B, A) | xs:dayTimeDuration |
fs:idiv (A, B) |
xs:integer |
xs:integer |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv (A, B) |
xs:decimal |
xs:decimal |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv (A, B) |
xs:float |
xs:float |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv (A, B) |
xs:double |
xs:double |
op:numeric-integer-divide(A, B) | xs:integer |
fs:div (A, B) |
xs:integer |
xs:integer |
op:numeric-divide(A, B) | xs:decimal |
fs:div (A, B) |
xs:decimal |
xs:decimal |
op:numeric-divide(A, B) | xs:decimal |
fs:div (A, B) |
xs:float |
xs:float |
op:numeric-divide(A, B) | xs:float |
fs:div (A, B) |
xs:double |
xs:double |
op:numeric-divide(A, B) | xs:double |
fs:div (A, B) |
xs:yearMonthDuration |
xs:double |
op:divide-yearMonthDuration(A, B) | xs:yearMonthDuration |
fs:div (A, B) |
xs:dayTimeDuration |
xs:double |
op:divide-dayTimeDuration(A, B) | xs:dayTimeDuration |
fs:div (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:divide-yearMonthDuration-by-yearMonthDuration(A, B) | xs:decimal |
fs:div (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:divide-dayTimeDuration-by-dayTimeDuration(A, B) | xs:decimal |
fs:mod (A, B) |
xs:integer |
xs:integer |
op:numeric-mod(A, B) | xs:integer |
fs:mod (A, B) |
xs:decimal |
xs:decimal |
op:numeric-mod(A, B) | xs:decimal |
fs:mod (A, B) |
xs:float |
xs:float |
op:numeric-mod(A, B) | xs:float |
fs:mod (A, B) |
xs:double |
xs:double |
op:numeric-mod(A, B) | xs:double |
fs:eq (A, B) |
xs:integer |
xs:integer |
op:numeric-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:decimal |
xs:decimal |
op:numeric-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:float |
xs:float |
op:numeric-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:double |
xs:double |
op:numeric-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:boolean |
xs:boolean |
op:boolean-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:string |
xs:string |
op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
fs:eq (A, B) |
xs:date |
xs:date |
op:date-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:time |
xs:time |
op:time-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:dateTime |
xs:dateTime |
op:dateTime-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:duration |
xs:duration |
op:duration-equal(A, B) | xs:boolean |
fs:eq (A, B) |
Gregorian | Gregorian | op:gYear-equal(A, B) etc. | xs:boolean |
fs:eq (A, B) |
xs:hexBinary |
xs:hexBinary |
op:hexBinary-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:base64Binary |
xs:base64Binary |
op:base64Binary-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:anyURI |
xs:anyURI |
op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
fs:eq (A, B) |
xs:QName |
xs:QName |
op:QName-equal(A, B) | xs:boolean |
fs:eq (A, B) |
xs:NOTATION |
xs:NOTATION |
op:NOTATION-equal(A, B) | xs:boolean |
fs:ne (A, B) |
xs:integer |
xs:integer |
fn:not (op:numeric-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:decimal |
xs:decimal |
fn:not (op:numeric-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:float |
xs:float |
fn:not (op:numeric-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:double |
xs:double |
fn:not (op:numeric-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:boolean |
xs:boolean |
fn:not (op:boolean-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:string |
xs:string |
fn:not (op:numeric-equal(fn:compare(A, B),
0)) |
xs:boolean |
fs:ne (A, B) |
xs:date |
xs:date |
fn:not (op:date-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:time |
xs:time |
fn:not (op:time-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:dateTime |
xs:dateTime |
fn:not (op:dateTime-equal(A,
B)) |
xs:boolean |
fs:ne (A, B) |
xs:duration |
xs:duration |
fn:not (op:duration-equal(A,
B)) |
xs:boolean |
fs:ne (A, B) |
Gregorian | Gregorian | fn:not (op:gYear-equal(A, B))
etc. |
xs:boolean |
fs:ne (A, B) |
xs:hexBinary |
xs:hexBinary |
fn:not (op:hexBinary-equal(A,
B)) |
xs:boolean |
fs:ne (A, B) |
xs:base64Binary |
xs:base64Binary |
fn:not (op:base64Binary-equal(A,
B)) |
xs:boolean |
fs:ne (A, B) |
xs:anyURI |
xs:anyURI |
fn:not (op:numeric-equal(fn:compare(A, B),
0)) |
xs:boolean |
fs:ne (A, B) |
xs:QName |
xs:QName |
fn:not (op:QName-equal(A, B)) |
xs:boolean |
fs:ne (A, B) |
xs:NOTATION |
xs:NOTATION |
fn:not (op:NOTATION-equal(A,
B)) |
xs:boolean |
fs:gt (A, B) |
xs:integer |
xs:integer |
op:numeric-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:decimal |
xs:decimal |
op:numeric-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:float |
xs:float |
op:numeric-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:double |
xs:double |
op:numeric-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:boolean |
xs:boolean |
op:boolean-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:string |
xs:string |
op:numeric-greater-than(fn:compare (A, B),
0) |
xs:boolean |
fs:gt (A, B) |
xs:date |
xs:date |
op:date-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:time |
xs:time |
op:time-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:dateTime |
xs:dateTime |
op:dateTime-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:yearMonthDuration-greater-than(A, B) | xs:boolean |
fs:gt (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:dayTimeDuration-greater-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:integer |
xs:integer |
op:numeric-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:decimal |
xs:decimal |
op:numeric-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:float |
xs:float |
op:numeric-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:double |
xs:double |
op:numeric-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:boolean |
xs:boolean |
op:boolean-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:string |
xs:string |
op:numeric-less-than(fn:compare (A, B),
0) |
xs:boolean |
fs:lt (A, B) |
xs:date |
xs:date |
op:date-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:time |
xs:time |
op:time-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:dateTime |
xs:dateTime |
op:dateTime-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:yearMonthDuration-less-than(A, B) | xs:boolean |
fs:lt (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:dayTimeDuration-less-than(A, B) | xs:boolean |
fs:ge (A, B) |
xs:integer |
xs:integer |
op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:ge (A, B) |
xs:decimal |
xs:decimal |
op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:ge (A, B) |
xs:float |
xs:float |
op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:ge (A, B) |
xs:double |
xs:double |
op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:ge (A, B) |
xs:boolean |
xs:boolean |
op:numeric-greater-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:ge (A, B) |
xs:string |
xs:string |
op:numeric-greater-than(fn:compare (A, B),
-1) |
xs:boolean |
fs:ge (A, B) |
xs:date |
xs:date |
op:date-less-than(B, A) | xs:boolean |
fs:ge (A, B) |
xs:time |
xs:time |
op:time-less-than(B, A) | xs:boolean |
fs:ge (A, B) |
xs:dateTime |
xs:dateTime |
op:dateTime-less-than(B, A) | xs:boolean |
fs:ge (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:yearMonthDuration-less-than(B, A) | xs:boolean |
fs:ge (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:dayTimeDuration-less-than(B, A) | xs:boolean |
fs:le (A, B) |
xs:integer |
xs:integer |
op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:le (A, B) |
xs:decimal |
xs:decimal |
op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:le (A, B) |
xs:float |
xs:float |
op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:le (A, B) |
xs:double |
xs:double |
op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:le (A, B) |
xs:boolean |
xs:boolean |
op:numeric-less-than(A, B) or op:numeric-equal(A,B) | xs:boolean |
fs:le (A, B) |
xs:string |
xs:string |
op:numeric-less-than(fn:compare (A, B),
1) |
xs:boolean |
fs:le (A, B) |
xs:date |
xs:date |
op:date-greater-than(B, A) | xs:boolean |
fs:le (A, B) |
xs:time |
xs:time |
op:time-greater-than(B, A) | xs:boolean |
fs:le (A, B) |
xs:dateTime |
xs:dateTime |
op:dateTime-greater-than(B, A) | xs:boolean |
fs:le (A, B) |
xs:yearMonthDuration |
xs:yearMonthDuration |
op:yearMonthDuration-greater-than(B, A) | xs:boolean |
fs:le (A, B) |
xs:dayTimeDuration |
xs:dayTimeDuration |
op:dayTimeDuration-greater-than(B, A) | xs:boolean |
fs:is-same-node (A, B) |
node() | node() | op:is-same-node |
xs:boolean |
fs:node-before (A, B) |
node() | node() | op:node-before |
xs:boolean |
fs:node-after (A, B) |
node() | node() | op:node-after |
xs:boolean |
| Internal Function | AtomicType1 | Denotes | AtomicType3 |
|---|---|---|---|
fs:unary-plus (A) |
xs:integer |
op:numeric-unary-plus(A) | xs:integer |
fs:unary-plus (A) |
xs:decimal |
op:numeric-unary-plus(A) | xs:decimal |
fs:unary-plus (A) |
xs:float |
op:numeric-unary-plus(A) | xs:float |
fs:unary-plus (A) |
xs:double |
op:numeric-unary-plus(A) | xs:double |
fs:unary-minus (A) |
xs:integer |
op:numeric-unary-minus(A) | xs:integer |
fs:unary-minus (A) |
xs:decimal |
op:numeric-unary-minus(A) | xs:decimal |
fs:unary-minus (A) |
xs:float |
op:numeric-unary-minus(A) | xs:float |
fs:unary-minus (A) |
xs:double |
op:numeric-unary-minus(A) | xs:double |
This section describes how XML Schema declarations, as specified by XML Schema are imported into the [XPath/XQuery] type system.
During schema import processing, the [XPath/XQuery] environment imports XML Schema declarations and loads them as declarations in the [XPath/XQuery] type system. The semantics of that loading process is defined by normalization rules that map XML Schema descriptions into the [XPath/XQuery] type system.
Here is summarized the XML Schema features which are covered by the formal semantics, and handled by the import mapping described in this section. For each feature, the following indications are used.
Handled indicates features that are relevant for [XPath/XQuery], are modeled in the [XPath/XQuery] type system, and are supported by the mapping.
Not in v1.0 indicates features that are relevant to [XPath/XQuery], but are not yet modeled in the [XPath/XQuery] type system or are not handled by the mapping in XQuery V1.0. In case the [XPath/XQuery] type system provides appropriate support for those features, but the mapping is incomplete, the additional annotation mapping only is used.
Not handled indicates features that are relevant for [XPath/XQuery], but are not modeled in the [XPath/XQuery] type system, and are not handled by the mapping. Such features are typically only related to validation, for which the formal semantics defines a partial model.
Ignored Indicates features that are not relevant for [XPath/XQuery], are not modeled in the [XPath/XQuery] type system, and are not relevant for the mapping. Such features might have to do with documentation of the schema, or might affect which Schemas are legal, but do not affect which documents match which Schemas.
Here is the exhaustive list of XML Schema features and their status in this document.
| Feature: | Supported |
| Primitive Simple types | Handled |
| Simple type derivation by restriction | Handled |
| Derivation by list and union | Handled |
| Facets on simple types | Not handled |
| ID and IDREF constraints | Ignored |
| Attribute Declarations | |
| default,fixed,use | Not in v1.0 |
| Element Declarations | |
| default, fixed (value constraint) | Not in v1.0 |
| nillable | Handled |
| substitution group affiliation | Handled |
| substitution group exclusions | Ignored |
| disallowed substitutions | Ignored |
| abstract | Not in v1.0 |
| Complex Type Definitions | |
| derivation by restriction | Handled |
| derivation by extension | Handled |
| final | Ignored |
| abstract | Not in v1.0 |
| AttributeUses | |
| required | Not in v1.0, mapping only |
| default, fixed (value constraint) | Not in v1.0 |
| Attribute Group Definitions | Not in v1.0, mapping only |
| Model Group Definitions | Not in v1.0, mapping only |
| Model Groups | Handled |
| Particles | Handled |
| Wildcards | |
| process contents strict, skip, lax | Ignored |
| namespace wild cards. | Ignored |
| Identity-constraint Definitions | Ignored |
| Notation Declarations | Ignored |
| Annotations | Ignored |
Note that the schema import feature specified here assumes it is given a legal schema as input. As a result, it is not necessary to check for 'block' or 'abstract' attributes.
The presentation of the schema mapping is done according to the following organization.
Schema component
First each schema component is summarized using the same notation used in the XML Representation Summary sections in XML Schema. For instance, here is the XML Representation Summary for complex types.
| <complexType |
| [ ignored ] abstract = boolean : false |
| [ ignored ] block = (#all | List of (extension | restriction)) |
| [ ignored ] final = (#all | List of (extension | restriction)) |
| [ ignored ] id = ID |
| mixed = boolean : false |
| name = NCName |
| [ ignored ] {any schemaAttributes with non-schema namespace ...} > |
| Content: (annotation?, (simpleContent | complexContent | ((group | all | choice | sequence)?, ((schemaAttribute | schemaAttributeGroup)*, anySchemaAttribute?)))) |
| </complexType> |
Attributes indicated as [ ignored ] are not mapped into the [XPath/XQuery] type system.
Attributes indicated as [ not handled ] are not currently handled by the mapping.
Note that in order to simplify the mapping, it is assumed that
the default values for all attributes in the XML Representation of
Schema are filled in. For instance in the above complex type, if
the mixed
attribute is not present, it will be treated
as being present and having the value "false"
.
Schema mapping
XML Schema import is specified by means of mapping rules. All mapping rules have the structure below.
| [SchemaComponent]Subscript |
| == |
| TypeComponent |
The SchemaComponent above the horizontal rule denotes an XML Schema component before translation and the TypeComponent beneath the horizontal rule denotes an equivalent type component in the [XPath/XQuery] type system.
Notation
Whenever necessary for the mapping rules, specific grammar productions which describe fragments of XML Schema may be introduced. For instance, here are grammar productions used to describes fragments of the XML Representation Summary for the complexType Element Information Item.
| [57 (Formal)] | ComplexTypeContent |
::= | "annotation"? ("simpleContent" | "complexContent" |
(ChildrenContent AttributeContent)) |
| [60 (Formal)] | AttributeContent |
::= | ("attribute" | "attributeGroup")*
"anyAttribute"? |
| [58 (Formal)] | ChildrenContent |
::= | ("group" | "all" | "choice" | "sequence")? |
As in the rest of this document, some mapping rules may use fragments of the XML Representation corresponding to the syntactic categories defined by those grammar productions. For instance, the following complex type fragment uses the syntactic categories: TypeName, ComplexTypeContent, and AttributeContent, ChildrenContent, and MixedAttribute.
| <complexType |
| name = TypeName |
| MixedAttribute > |
| ChildrenContent AttributeContent |
| </complexType> |
Notation
The normalization rule
| [Schema]Schema |
| == |
| Definitions |
maps a complete schema into a set of Definitions in the [XPath/XQuery] type system.
The normalization rule
| [SchemaComponent]definition(targetNCName) |
| == |
| Definition |
maps a top level schema component into a Definition in the [XPath/XQuery] type system, given the target namespace targetAnyURI.
The normalization rule
| [SchemaComponent]content(targetNCName) |
| == |
| TypeComponent |
maps a schema component not directly under the schema element, into a TypeComponent in the [XPath/XQuery] type system, given the target namespace targetAnyURI.
The XML Schema attributes: use, default, fixed, minOccurs, maxOccurs, mixed, nillable, and substitutionGroup, require specific mapping rules.
The "use", "default", and "fixed" attributes are used to describe the occurrence and default behavior of a given attribute.
Notation
The following auxiliary grammar productions are used to describe the "use", "default", and "fixed" attributes.
| [61 (Formal)] | UseAttribute |
::= | "use" "=" ("optional" | "prohibited" |
"required") |
| [62 (Formal)] | DefaultAttribute |
::= | "default" "=" String |
| [63 (Formal)] | FixedAttribute |
::= | "fixed" "=" String |
The normalization rule
| [UseAttribute DefaultAttribute? FixedAttribute? ]use |
| == |
| OccurrenceIndicator |
maps a combination of a use attribute UseAttribute, along with an optional default or fixed attribute in Schema into the occurrence indicator OccurrenceIndicator in the [XPath/XQuery] type system.
Schema mapping
Use attributes are mapped to the type system in the following way. In case there is a default or fixed attribute, the attribute is always present in the PSVI and the use attribute is ignored.
| UseAttribute DefaultAttributeuse |
| == |
| 1 |
| UseAttribute FixedAttributeuse |
| == |
| 1 |
| use = "optional"use |
| == |
| ? |
| use = "required"use |
| == |
| 1 |
| Editorial note | |
| Issue: how derivation of attribute declaration and the "prohibited" use attributes are mapped in the [XPath/XQuery] type system is still an open issue. |
Notation
The following auxiliary grammar productions are used to describe occurrence attributes and the length facets.
| [56 (Formal)] | OccursAttributes |
::= | maxOccurs | minOccurs | maxLength | minLength | length |
| [54 (Formal)] | maxOccurs |
::= | "maxOccurs" "=" ("nonNegativeInteger" |
"unbounded") |
| [55 (Formal)] | minOccurs |
::= | "minOccurs" "=" "nonNegativeInteger" |
| [51 (Formal)] | maxLength |
::= | "maxLength" "=" "nonNegativeInteger" |
| [52 (Formal)] | minLength |
::= | "minLength" "=" "nonNegativeInteger" |
| [53 (Formal)] | length |
::= | "length" "=" "nonNegativeInteger" |
The normalization rule
| [OccursAttributes]occurs |
| == |
| OccurrenceIndicator |
maps the occurrence attributes and facets OccursAttributes in Schema into the occurrence indicator OccurrenceIndicator in the [XPath/XQuery] type system.
Schema mapping
Occurrence attributes are mapped to the type system in the following way.
| [minOccurs="0" maxOccurs="1"]occurs |
| == |
| ? |
| [minOccurs="1" maxOccurs="1"]occurs |
| == |
| [minOccurs="0" maxOccurs="n"]occurs |
| == |
| * |
| [minOccurs="1" maxOccurs="n"]occurs |
| == |
| + |
where n > 1.
| [minOccurs="n" maxOccurs="m"]occurs |
| == |
| + |
where m >= n > 1
| [minLength="0" maxLength="1"]occurs |
| == |
| ? |
| [minLength="1" maxLength="1"]occurs |
| == |
| [minLength="0" maxLength="n"]occurs |
| == |
| * |
| [minLength="1" maxLength="n"]occurs |
| == |
| + |
where n > 1.
| [minLength="n" maxLength="m"]occurs |
| == |
| + |
where m >= n > 1
| [length="1"]occurs |
| == |
| [length="n"]occurs |
| == |
| + |
where n > 1
Notation
The following auxiliary grammar productions are used to describe the "mixed" attribute.
| [48 (Formal)] | MixedAttribute |
::= | "mixed" "=" Boolean |
The normalization rule
maps the mixed attribute MixedAttribute in Schema into a Mixed notation in the [XPath/XQuery] type system.
Schema mapping
If the mixed attribute is true it is mapped to a mixed notation in the [XPath/XQuery] type system.
| [ mixed = "true" ]mixed |
| == |
| mixed |
If the mixed attribute is false it is mapped to empty in the [XPath/XQuery] type system.
| [ mixed = "false" ]mixed |
| == |
Notation
The following auxiliary grammar productions are used to describe the "nillable" attribute.
| [49 (Formal)] | NillableAttribute |
::= | "nillable" "=" Boolean |
The normalization rule
maps the nillable attribute NillableAttribute in Schema into a Nillable notation in the [XPath/XQuery] type system.
Schema mapping
If the nillable attribute is true it is mapped to a nillable notation in the [XPath/XQuery] type system.
| [ nillable = "true" ]nillable |
| == |
| nillable |
If the nillable attribute is false it is mapped to empty in the [XPath/XQuery] type system.
| [ nillable = "false" ]nillable |
| == |
Notation
The substitution group declaration indicates the element that a given element can be substituted for. The following auxiliary grammar productions are used to describe the "substitutionGroup" attribute.
| [50 (Formal)] | substitutionGroupAttribute |
::= | "substitutionGroup" "=" QName |
The normalization rule
| [substitutionGroupAttribute]substitution |
| == |
| Substitution |
maps the substitutionGroup attribute substitutionGroupAttribute in Schema into a Substitution notation in the [XPath/XQuery] type system.
Schema mapping
If the substitutionGroup attribute is present, it is mapped to a substitutionGroup notation in the [XPath/XQuery] type system.
| [ substitutionGroup = QName ]substitution |
| == |
| substitutes for QName |
Otherwise, it is mapped to empty.
Notation
As explained in [2.4 The [XPath/XQuery] Type System], the [XPath/XQuery] type uses system-generated type names for anonymous types. For the purpose of this document those type names are generated at XML Schema import time.
Schema component
A schema is represented in XML by the following structure.
| <schema |
| [ not handled ] attributeFormDefault = (qualified | unqualified) : unqualified |
| [ ignored ] blockDefault = (#all | List of (extension | restriction | substitution)) : ' ' |
| [ not handled ] elementFormDefault = (qualified | unqualified) : unqualified |
| [ ignored ] finalDefault = (#all | List of (extension | restriction)) : ' ' |
| [ ignored ] id = ID |
| targetNamespace = anyURI |
| [ ignored ] version = token |
| [ ignored ] xml:lang = language |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: ((include | import | redefine | annotation)*, (((simpleType | complexType | group | attributeGroup) | element | attribute | notation), annotation*)*) |
| </schema> |
Notation
The following auxiliary grammar productions are used.
| [46 (Formal)] | SPragma |
::= | ("include" | "import" | "redefine" |
"annotation")* |
| [47 (Formal)] | Content |
::= | (("simpleType" | "complexType" | "element" | "attribute"
| "attributeGroup" | "group" | "notation")
"annotation"*)* |
The auxiliary normalization rule
| [Pragma]pragma(targetAnyURI) |
| == |
| Definitions |
maps the a schema pragma into a set of definitions in the [XPath/XQuery] type system.
Schema mapping
Schemas are imported by the "schema" declaration in the preamble of a query. To import a schema, the document referred to by the given URI is opened and the schema declarations contained in the document are translated into the corresponding in-line type definitions. The mechanism for finding a schema document, possibly using the optional schema location hint, is not specified formally.
| [schema StringLiteral (at StringLiteral)?]Schema |
| == |
| [open-schema-document(StringLiteral (at StringLiteral)?)]Schema |
[
|
||||
| == | ||||
| [Pragma]pragma(targetAnyURI) [Content]definition(targetNCName) |
Schema component
A schema include is represented in XML by the following structure.
| <include |
| [ ignored ] id = ID |
| schemaLocation = anyURI |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: (annotation?) |
| </include> |
Schema mapping
A schema include is not specified here, and is assumed to be handled by the XML Schema processor.
Schema component
A schema redefinition is represented in XML by the following structure.
| <redefine |
| [ ignored ] id = ID |
| schemaLocation = anyURI |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: (annotation | (simpleType | complexType | group | attributeGroup))* |
| </redefine> |
Schema mapping
A schema redefine is not specified here, and is assumed to be handled by the XML Schema processor.
Schema component
A schema import is represented in XML by the following structure.
| <import |
| [ ignored ] id = ID |
| namespace = anyURI |
| schemaLocation = anyURI |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: (annotation?) |
| </import> |
Schema mapping
A schema import is not specified here, and is assumed to be handled by the XML Schema processor.
Schema component
The following structure describes attribute declarations in XML Schema.
| <attribute |
| [ not handled ] default = string |
| [ not handled ] fixed = string |
| [ not handled ] form = (qualified | unqualified) |
| [ ignored ] id = ID |
| name = NCName |
| ref = QName |
| type = QName |
| use = (optional | prohibited | required) : optional |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: (annotation?, (simpleType?)) |
| </attribute> |
Schema import distinguishes between global attribute declarations and local attribute declarations.
Schema mapping
Global attribute declarations are mapped like local attribute declarations, but are prefixed by a "define" keyword in the [XPath/XQuery] type system.
| [AttributeDecl]definition(targetNCName) |
| == |
| define [AttributeDecl]content(targetNCName) |
Schema mapping
Local attributes whose type is given by a reference to a global type name are mapped in the type system as follows.
[
|
||||
| == | ||||
| ( attribute targetNCName:NCName { of type QName } )[UseAttribute]use |
References to a global attribute are mapped in the type system as follows.
[
|
|||
| == | |||
| ( attribute QName )[UseAttribute]use |
A local attribute with a local content is mapped to the [XPath/XQuery] type system as follows. Let fs:anonk be a newly generated anonymous name.
[
|
|||||
| == | |||||
|
Schema component
The following structure describes attribute declarations in XML Schema.
| <element |
| [ ignored ] abstract = boolean : false |
| [ ignored ] block = (#all | List of (extension | restriction)) |
| [ not handled ] default = string |
| [ ignored ] final = (#all | List of (extension | restriction)) |
| [ not handled ] fixed = string |
| [ not handled ] form = (qualified | unqualified) |
| [ ignored ] id = ID |
| maxOccurs = (nonNegativeInteger | unbounded) : 1 |
| minOccurs = nonNegativeInteger : 1 |
| name = NCName |
| nillable = boolean : false |
| ref = QName |
| substitutionGroup = QName |
| type = QName |
| [ ignored ] {any attributes with non-schema namespace ...} > |
| Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*)) |
| </element> |
Schema import distinguishes between global element declarations and local element declarations.
Schema mapping
Global element declarations are mapped like local element declarations, but are prefixed by a "define" keyword in the [XPath/XQuery] type system.
[
|
|||||
| == | |||||
| define element targetNCName:NCName [substitutionGroupAttribute]substitution [NillableAttribute]nillable of type QName |
[
|
||||||
| == | ||||||
| define element targetNCName:NCName [substitutionGroupAttribute]substitution [NillableAttribute]nillable [ElementModel]content(targetNCName) |
Schema mapping
Local element declarations, but mapped into corresponding notations in the [XPath/XQuery] type system. Note that substitution group cannot be declared on local elements.
[
|
|||||
| == | |||||
| ( element targetNCName:NCName [NillableAttribute]nillable of type QName ) [OccursAttributes]occurs |
[
|
|||
| == | |||
| ( element QName ) [OccursAttributes]occurs |
Let fs:anonk be a newly generated anonymous name.
[
|
||||||
| == | ||||||
|
Schema component
A complex type definition is represented in XML by the following structure.
| <complexType |
| [ ignored ] abstract = boolean : false |
| [ ignored ] block = (#all | List of (extension | restriction)) |
| [ ignored ] final = (#all | List of (extension | restriction)) |
| [ ignored ] id = ID |
| mixed = boolean : false |
| name = NCName |
| [ ignored ] {any attributes with non-schema namespace ...} > |