[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: Thu, 3 Jan 2008 22:24:01 +0800

Re:  Problem about imported schema type when processing XQuery
Ok, let me make it more concise. It's true that the ISSD is a static context, while
participating ISSD, in my understanding, include following schema definitions:
1 the module itself imported schema definitions
2 XML document imported schema definitions
3 those schema definitions imported in imported modules, and used to describe variable
 values and function arguments and return values(typically by subtype substitution). In other word, those schema definitions that only used to describe imported module's local variables does not belong to importing module's participating ISSD because they have nothing to do
with importing module.

What's more, even if we could forgot the scenario that two types in two files have identical  QName,
we still could not avoid  the  "redefine" mechanism in schema, which did allow two types
have identical name while have different different definitions. Let's take my original case as
an example, if we change schema_c.xsd to:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified" attributeFormDefault="qualified"
    <extension base="simple:myType">
        <xs:minInclusive value = "51"/>
        <xs:maxInclusive value = "100"/>

Then I think the case should be all right, isn't it? So, what's the result?
I think the type "simple:myType" will have different meaning in a.xq
and c.xq, processor should treat them correctly and should not complain, right?

I think if we consider participating ISSD is a dynamic concept, such scenario will be quite
natural to handle.


2008/1/3, Michael Kay < mike@s...>:
Sorry, I don't see how you can read the spec that way. ISSD is defined "as the in-scope schema definitions of a module", and "in-scope schema definitions" is clearly defined in 2.1.1 as part of the static context. This rule is clearly a static rule.
You say "I think participating ISSD is not a static concept, but a dynamic one", but you don't really explain why you think this.
Or perhaps I'm misunderstanding you, and you're not talking about what the spec says, but about what you think it should say? That's a different discussion, of course.
Michael Kay

From: he harrison [mailto:harrison076@g...]
Sent: 03 January 2008 02:00
To: Michael Kay
Cc: xml-dev@l...
Subject: Re: Problem about imported schema type when processing XQuery module import

That still seems obscure....how about my understanding:

My understanding is, for the most part, agree with yours explaination, the difference
is about "participating ISSD", I think participating ISSD is not a static concept,
but a dynamic one, it should not include all schema definitions in imported module,
but only those schema definitions that passed to importing module along with variables
or function return values. Those schema definitions in imported modules which are not
used by importing modules do not belong to participating ISSD.
Besides, participating ISSD also include currently active XML document
imported schema definitions, and module itself imported schema definitions.
As to my previous example, module a.xq's imported schema schema_a.xsd is
module c.xq's participating ISSD(because the type are passed by sub typing),
schema_c.xsd also belongs to c.xq's participating ISSD, while they both contain
same definition for "myType", therefore an dynamic error should be raised.
But if we change a.xq to:

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) cast as xs:int

then no error should be raised even a.xq and c.xq still have different ISSD that contain
different definition for "myType", because "myType" imported in a.xq will not be
passed to module c.xq therefore will not cause confusion.

I think this understanding is in consistant with both "2.2.5 Consistency Constraints"
and the two spec. statements I've mentioned.


2008/1/3, Michael Kay <mike@s...>:
Since it does not import in-scope schema definitions from the imported modules, the importing
module should not see what schema definitions are there in the imported modules.Since they
could not see each other, then how could they decide whether their ISSD is "equivalent"?
and it seems also meaningless to compare their ISSD because they will not disturb each
This may be why the spec doesn't require an implementation to check that the two ISSDs are compatible, but merely says that the results are unpredictable if they are not. 

If a module could see the imported module's schema definition, then why spec. still
force the importing module explicitly import necessary schema definition, since these types
will surely be imported from other module's ISSD?

XSLT took the decision that all imported schema definitions would be available in all modules. However, that makes it harder to do separate compilation of modules. I think the rule in XQuery that each module must import all the schema definitions that it needs is there in the belief that this will make separate compilation of modules easier.
Michael Kay

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
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.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.