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

[Bug 15688] [XQ30] Effect of prohibiting the serialization option

From: <bugzilla@jessica.w3.org>
Date: Tue, 14 Feb 2012 15:15:26 +0000
To: public-qt-comments@w3.org
Message-Id: <E1RxK6I-00085Y-6R@jessica.w3.org>

--- Comment #1 from Jonathan Robie <jonathan.robie@gmail.com> 2012-02-14 15:15:25 UTC ---
(In reply to comment #0)
> It's pretty clear what effect prohibiting the following optional features will
> have:
> schema-import: Raise XQST0009 on schema import.
> schema-validation: Raise XQST0075 on validate expressions.
> static-typing: Don't raise XPTY0004, XPST0005 for some expressions.
> module: Raise XQST0016 on module declaration or module import.
> But it's not quite so clear what disabling the serialization feature will do.

If you disable the serialization feature, then:

* You must not serialize the results of a query according to the serialization
* You still must support fn:serialize(), unless we make it an optional feature
during CR - it is not an error to call fn:serialize() in a query if the
serialization feature is disabled.
* You can still do a vendor-defined serialization
* You can still return results of a query in a non-serialized format, e.g. a
DOM tree

> Does it cause an implementation-defined error to be raised if the user attempts
> to serialize the results of a query (via the implementation's API)?

Our specification does not know anything about the implementation's API, this
question is out of scope.

> Does it cause errors to be raised when output declarations are encountered?

No, this is not an error.

> Does it cause fn:serialize to raise an error?

No, this is not an error.

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, 14 February 2012 15:15:30 UTC

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