W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2011

[Bug 15075] New: [XQuery30] D Implementation-Defined Items

From: <bugzilla@jessica.w3.org>
Date: Tue, 06 Dec 2011 01:09:20 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-15075-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15075

           Summary: [XQuery30] D Implementation-Defined Items
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: minor
          Priority: P2
         Component: XQuery 3.0
        AssignedTo: jonathan.robie@gmail.com
        ReportedBy: andrew.eisenberg@us.ibm.com
         QAContact: public-qt-comments@w3.org
             Group: XSLXQuery_WG


I did a scan of implementation-defined items in XQuery 3.0. I believe that the
following are not reflected in Appendix D, Implementation-Defined Items:


2.1.1 Static Context

The statically known function signatures include the signatures of functions
from a variety of sources, including built-in functions described in [XQuery
and XPath Functions and Operators 3.0], functions declared in the current
module (see 4.18 Function Declaration), module imports (see 4.12 Module
Import), constructor functions (see 3.16.5 Constructor Functions), and
functions provided by an implementation or via an implementation-defined API
(see C.1 Static Context Components). It is a static error [err:XQST0034] if two
such functions have the same expanded QName and the same arity (even if the
signatures are consistent).

2.1.2 Dynamic Context

[Definition: Environment variables. This is a mapping from names to values.
Both the names and the values are strings. The names are compared using an
implementation-defined collation, and are unique under this collation. The set
of environment variables is implementation-defined and may be empty.]

2.2.3.1 Static Analysis Phase

In XQuery 1.0 and XPath 2.0, rules for static type inferencing were published
normatively in [XQuery 1.0 and XPath 2.0 Formal Semantics], but implementations
were allowed to refine these rules to infer a more precise type where possible.
In XQuery 3.0 and XPath 3.0, the rules for static type inferencing are entirely
implementation-defined.

2.2.4 Serialization

An output declaration may appear only in a main module; it is a static error
[err:XQST0108] if an output declaration appears in a library module. It is a
static error [err:XQST0110] if the same serialization parameter is declared
more than once. It is a static error [err:XQST0109] if the local name of an
output declaration in the http://www.w3.org/2010/xslt-xquery-serialization
namespace is not one of the serialization parameter names listed in C.1 Static
Context Components or parameter-document. The default value for the method
parameter is "xml". An implementation may define additional
implementation-defined serialization parameters in its own namespaces.

2.2.4 Serialization

If the local name of an output declaration in the
http://www.w3.org/2010/xslt-xquery-serialization namespace is
parameter-document, the value of the output declaration is treated as a URI
literal. The value is a location hint, and identifies an XDM instance in an
implementation-defined way. If a processor is performing serialization, it is a
static error [err:XQST0119] if the implementation is not able to process the
value of the output:parameter-document declaration to produce an XDM instance.

2.2.5 Consistency Constraints

For each function declared as external: the implementationDM30 must either
return a value that matches the declared result type, using the matching rules
in 2.5.5 SequenceType Matching, or raise an implementation-defined error.

2.5.5.7 Function Test

Implementations MAY define further annotation assertions, whose behaviour is
implementation-defined. Implementations MAY provide a way for users to create
their own annotation assertions. Implementations MUST NOT define annotation
assertions in the following reserved namespaces; it is an error for users to
create annotation assertions in the following reserved namespaces
[err:XQST0045]:

2.5.6.3 The judgement subtype-assertions(AnnotationsA, AnnotationsB)

The judgement subtype-assertions(AnnotationsA, AnnotationsB) determines if
AnnotationsA is a subtype of AnnotationsB, where AnnotationsA and AnnotationsB
are annotation lists from two FunctionTests. It is defined to ignore annotation
assertions in namespaces not understood by the XQuery implementation. For
assertions that are understood, their effect on the result of
subtype-assertions() is implementation defined.

3.1.2 Variable References

The in-scope variables may be augmented by implementation-defined variables.

3.11 Ordered and Unordered Expressions

In addition to ordered and unordered expressions, XQuery provides a function
named fn:unordered that operates on any sequence of items and returns the same
sequence in an implementation-defined order. A call to the fn:unordered
function may be thought of as giving permission for the argument expression to
be materialized in whatever order the system finds most efficient. The
fn:unordered function relaxes ordering only for the sequence that is its
immediate operand, whereas an unordered expression sets the ordering mode for
its operand expression and all nested expressions.

3.15 Try/Catch Expressions

err:additional item()* Implementation-defined. This variable must be bound so
that a query can reference it without raising an error. The purpose of this
variable is to allow implementations to provide any additional information that
might be useful.

4.3 Boundary-space Declaration

[Definition: A boundary-space declaration sets the boundary-space policy in the
static context, overriding any implementation-defined default. Boundary-space
policy controls whether boundary whitespace is preserved by element
constructors during processing of the query.] If boundary-space policy is
preserve, boundary whitespace is preserved. If boundary-space policy is strip,
boundary whitespace is stripped (deleted). A further discussion of whitespace
in constructed elements can be found in 3.9.1.4 Boundary Whitespace.

4.4 Default Collation Declaration

[Definition: A default collation declaration sets the value of the default
collation in the static context, overriding any implementation-defined
default.] The default collation is the collation that is used by functions and
operators that require a collation if no other collation is specified. For
example, the gt operator on strings is defined by a call to the fn:compare
function, which takes an optional collation parameter. Since the gt operator
does not specify a collation, the fn:compare function implements gt by using
the default collation.

4.5 Base URI Declaration

In the terminology of [RFC3986] Section 5.1, the URILiteral of the base URI
declaration is considered to be a "base URI embedded in content". If no base
URI declaration is present, Static Base URI property is established according
to the principles outlined in [RFC3986] Section 5.1—that is, it defaults first
to the base URI of the encapsulating entity, then to the URI used to retrieve
the entity, and finally to an implementation-defined default. If the URILiteral
in the base URI declaration is a relative URI, then it is made absolute by
resolving it with respect to this same hierarchy. For example, if the
URILiteral in the base URI declaration is ../data/, and the query is contained
in a file whose URI is file:///C:/temp/queries/query.xq, then the Static Base
URI property is file:///C:/temp/data/.

4.6 Construction Declaration

[Definition: A construction declaration sets the construction mode in the
static context, overriding any implementation-defined default.] The
construction mode governs the behavior of element and document node
constructors. If construction mode is preserve, the type of a constructed
element node is xs:anyType, and all attribute and element nodes copied during
node construction retain their original types. If construction mode is strip,
the type of a constructed element node is xs:untyped; all element nodes copied
during node construction receive the type xs:untyped, and all attribute nodes
copied during node construction receive the type xs:untypedAtomic.

4.7 Ordering Mode Declaration

[Definition: An ordering mode declaration sets the ordering mode in the static
context, overriding any implementation-defined default.] This ordering mode
applies to all expressions in a module (including both the Prolog and the Query
Body, if any), unless overridden by an ordered or unordered expression.

4.8 Empty Order Declaration

[Definition: An empty order declaration sets the default order for empty
sequences in the static context, overriding any implementation-defined default.
This declaration controls the processing of empty sequences and NaN values as
ordering keys in an order by clause in a FLWOR expression.] An individual order
by clause may override the default order for empty sequences by specifying
empty greatest or empty least.

4.9 Copy-Namespaces Declaration

[Definition: A copy-namespaces declaration sets the value of copy-namespaces
mode in the static context, overriding any implementation-defined default.
Copy-namespaces mode controls the namespace bindings that are assigned when an
existing element node is copied by an element constructor or document
constructor.] Handling of namespace bindings by element constructors is
described in 3.9.1 Direct Element Constructors.

4.12 Module Import

[Definition: A module import imports the public variable declarations and
public function declarations from one or more library modules into the
statically known function signatures and in-scope variables of the importing
module.] Each module import names a target namespace and imports an
implementation-defined set of modules that share this target namespace. The
module import may bind a namespace prefix to the target namespace, adding the
(prefix, URI) pair to the statically known namespaces, and it may provide
optional hints for locating the modules to be imported.

4.15 Annotations

Implementations MAY define further annotations, whose behaviour is
implementation-defined. For instance, if the eg prefix is bound to a namespace
associated with a particular implementation, it could define an annotation like
eg:sequential. Implementations MUST NOT define annotations in the following
reserved namespaces; it is an error for users to create annotations in the
following reserved namespaces [err:XQST0045]:

4.16 Variable Declaration

if a value is provided for the variable by the external environment, then V is
that value. The means by which typed values of external variables are provided
by the external environment is implementation-defined.

4.17 Context Item Declaration

The means by which an external value is provided by the external environment is
implementation-defined.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 6 December 2011 01:09:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:37 UTC