This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. 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)? Does it cause errors to be raised when output declarations are encountered? Does it cause fn:serialize to raise an error?
(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 spec. * 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.
Jonathan will add a NOTE to clarify this in the spec.
We have decided that fn:serialize() must be provided by all implementations, but an implementation can simply raise an error when it is called if it chooses not to provide this functionality. I will mention this in the note in the previous comment. The actual specification will be in F&O.