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

[Bug 19602] New: [XQ30] Features not scoped to a module

From: <bugzilla@jessica.w3.org>
Date: Thu, 18 Oct 2012 13:48:09 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-19602-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19602

          Priority: P2
            Bug ID: 19602
          Assignee: jonathan.robie@gmail.com
           Summary: [XQ30] Features not scoped to a module
        QA Contact: public-qt-comments@w3.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: mike@saxonica.com
          Hardware: PC
            Status: NEW
           Version: Last Call drafts
         Component: XQuery 3.0
           Product: XPath / XQuery / XSLT

When prohibit feature is used in a module, the specification states that the
implementation must behave as if that feature is not enabled in that module.

However, not all aspects of optional features are scoped to a module, and this
creates difficulties if a feature is enabled in one module but disabled in
another. For example, the schema-aware feature "permits an XDM to contain types
other than xs:untyped and xs:untypedAtomic", and it makes no sense to allow
this in one module and not in others. Similar problems apply to the
serialization feature.

Although it's plausible to allow fn:serialize to be called in one module, but
not to be available in another module, I would hope that there is no
expectation that fn:lookup("fn:serialize") succeeds in one case and fails in
the other - that's too much of a burden for implementations to justify any
value.

I would like to agree the principle that prohibit-feature is only required to
disable things that can be detected statically.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 18 October 2012 13:48:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 18 October 2012 13:48:15 GMT