[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: Problem about imported schema type when processing XQuery
- From: "he harrison" <harrison076@g...>
- To: "Michael Kay" <mike@s...>
- Date: Wed, 2 Jan 2008 21:26:01 +0800
Hi, Micheal, thanks for your reply, however I am still in doubt. According to the definition of "participating ISSD", it's a kind of
in-scope schema definitions,
then whether
in-scope schema definitions include schemas imported in other imported modules?
There are two statement in spec.:
A module import imports
only functions and variable declarations; it does not import other objects from
the imported modules, such as in-scope schema definitions or
statically known
namespaces. and
It is a static error [err:XQST0036] to import a
module if the importing module's in-scope schema types do not
include definitions for the schema type names that appear in the declarations of
variables and functions (whether in an argument type or return type) that are
present in the imported module and are referenced in the importing
module. From upon two statement, we could make the conclusion that
in-scope schema definitions should not include
schemas imported in other imported modules, otherwise
[err:XQST0036]
will be unnecessary,
therefore "participating ISSD" should also not include schemas imported in other imported modules, right?
So I think two modules import identical type qname with different difinition is not an error,
unless variables with one of the types are passed to another module.
The section 2.2.5's constraints that require the
types derived from validating input documents to be consistent with those that
are imported into the static context helps me to clarify another problem, thanks.
2008/1/2, Michael Kay <mike@s...
>:
I think the mailing list at talk@x...
would be a better place for
such a question. As it happens, your question is very similar to one raised this
morning on that list by Weihua Jiang of Intel.
I believe that your query violates the rule in the
penultimate bullet of 2.2.5 in the XQuery specification:
"For a
given query, define a participating ISSD as the
in-scope schema definitions of a module that is used in evaluating the query. If two
participating ISSDs contain a definition for the same schema type, element name,
or attribute name, the definitions must be equivalent in both
ISSDs."
The introductory paragraph of 2.2.5 says "This specification does not define
the result of a query under
any condition in which one or more of these constraints is not satisfied." - in other words, it's an error to have two
different types with the same name, but it's not an error that an implementation
is required to detect and report. So it's not surprising that you get different
results from different processors, nor that the results are "obviously
wrong".
Section 2.2.5 also imposes constraints that require the
types derived from validating input documents to be consistent with those that
are imported into the static context.
Michael Kay
http://www.saxonica.com/
From: he harrison
[mailto:harrison076@g...] Sent: 02 January 2008
03:12 To: xml-dev@l... Subject: Problem
about imported schema type when processing XQuery module
import
Hi, I come up with a problem when reading XQuery spec., following
is my case:
a.xq:
module namespace ma="http://www.w3.org/TestModules/moduleA
"; import
schema namespace simple="http://www.w3.org/XQueryTest/simple"
at "schema_a.xsd"; declare function ma:funcA() { "40"
cast as simple:myType };
b.xq:
module namespace mb="http://www.w3.org/TestModules/moduleB"; import
module namespace ma="http://www.w3.org/TestModules/moduleA" at "a.xq"; declare function
mb:funcB() { ma:funcA() treat as
xs:integer };
c.xq:
declare namespace mc="http://www.w3.org/TestModules/moduleC"; import module namespace mb="http://www.w3.org/TestModules/moduleB"
at "b.xq"; import schema namespace simple=" http://www.w3.org/XQueryTest/simple
"
at "schema_c.xsd";
declare function mc:funcC() {
mb:funcB() instance of
simple:myType };
<result>{mc:funcC()}</result>
schema_a.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:simple="http://www.w3.org/XQueryTest/simple"
targetNamespace="http://www.w3.org/XQueryTest/simple"
elementFormDefault="qualified" attributeFormDefault="qualified"
> <xs:simpleType name =
"myType"> <xs:restriction base =
"xs:int"> <xs:minInclusive value =
"1"/> <xs:maxInclusive value =
"50"/> </xs:restriction>
</xs:simpleType>
</xs:schema>
schema_c.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema "
xmlns:simple="http://www.w3.org/XQueryTest/simple"
targetNamespace="http://www.w3.org/XQueryTest/simple"
elementFormDefault="qualified"
attributeFormDefault="qualified" > <xs:simpleType name =
"myType"> <xs:restriction base =
"xs:int"> <xs:minInclusive value =
"51"/> <xs:maxInclusive value =
"100"/> </xs:restriction>
</xs:simpleType> </xs:schema>
Main
module is c.xq, what should be output? The key problem is, whether we need
to keep different type definition in each module, in case imported types
have same name and actually are different? I tried some XQuery processors,
they all give different result and most of them are obviously wrong...
Another further problem is, if we choose to ignore types imported from
other modules, while we need to recognize types bring by XML
documents, then it seems confusion when we handle a returned value of a
function, as we need to distinguish where the value comes from: defined by
module or get from document.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|