W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2012

[Bug 15390] [QT3TS] Serialization tests too liberal about errors

From: <bugzilla@jessica.w3.org>
Date: Fri, 05 Oct 2012 21:37:57 +0000
Message-Id: <E1TKFan-0004tx-VN@jessica.w3.org>
To: public-qt-comments@w3.org

Jonathan Robie <jonathan.robie@gmail.com> changed:

           What    |Removed                     |Added
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Jonathan Robie <jonathan.robie@gmail.com> 2012-10-05 21:37:57 UTC ---
The XQuery specification (internal draft) now says errors that are not
recognized should be silently ignored::

[XSLT and XQuery Serialization 3.0] defines a set of serialization parameters
that govern the serialization process. If an XQuery implementation provides a
serialization interface, it may support (and may expose to users) any of the
serialization parameters listed (with default values) in C.1 Module Static
Context. If an implementation does not support one of these parameters, it must
ignore it without raising an error.

It also specifies the names and values:

[Definition: An output declaration is an option declaration in the namespace
"http://www.w3.org/2010/xslt-xquery-serialization"; it is used to declare
serialization parameters.] Except for parameter-document, each option
corresponds to a serialization parameter element defined in Section B Schema
for Serialization Parameters SER30. The name of each option is the same as the
name of the corresponding serialization parameter element, and the values
permitted for each option are the same as the values allowed in the
serialization parameter element. There is no output declaration for
use-character-maps, it can be set only by means of a parameter document.

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 Friday, 5 October 2012 21:37:59 UTC

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