W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2010

[Bug 8129] [XQTS] CVS: location hints

From: <bugzilla@jessica.w3.org>
Date: Mon, 28 Jun 2010 15:23:36 +0000
To: public-qt-comments@w3.org
Message-Id: <E1OTGBM-0005xv-36@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8129


John Snelson <john.snelson@marklogic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #13 from John Snelson <john.snelson@marklogic.com>  2010-06-28 15:23:35 ---
(In reply to comment #11)
> Firstly, module3-lib and module4-lib still use a location hint to load the
> schema.

Fixed.

> modules-21 is as follows:
> It expects (non-existant) error XQST0081.  I assume it should have been be
> XPST0081 (unbound prefix).

I agree.

> However the imported module uses the schema with target namespace
> "http://www.w3.org/TestModules/defs" and so I believe that XQST0036 is also
> appropriate.
> 
> This also applies to modules-23 and modules-24

I think that modules-23 doesn't use an undefined prefix, and should not
therefore raise XPST0081.

Otherwise agreed and fixed.

> The tests modules-25, modules-26 and modules-27 all import module4-lib.xq

Well, they did until a fix for Bug #9955 was committed which screwed them up.
After a bit of CVS archaeology, I think the correct thing to do is to change
them back to use module4-lib again.

> In several places in this module a newly constructed attribute (with type
> annotation xs:untypedAtomic) is used where a schema-attribute(sample:attrib) is
> expected.  Thus I believe any test importing this module should also expect
> XPTY0004, which seems to undermine the test.

Agreed.

> The module could be fixed by validating the constructed attributes, although
> this doesn't seem to be possible in XQuery (why can we only validate
> elements?).  The only way to fix this test is either to use the type
> schema-attribute(sample:attrib)? and the value (), or to expand the schema such
> that we can validate an element containing a sample:attrib attribute and then
> extract the attribute.

I've fixed these tests by making them accept zero-or-more schema attributes.

> validate-constraints-1 - 4 are all marked isXPath2="true" when they are not
> valid XPath 2 tests.

Fixed.

Again, please test the fixes, and mark the bug as closed if you agree with my
solutions.

-- 
Configure bugmail: http://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 Monday, 28 June 2010 15:23:37 UTC

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