[Bug 5738] [XQuery] Constraints on schemas

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5738





--- Comment #6 from Jonathan Robie <jonathan.robie@redhat.com>  2008-07-30 15:04:34 ---
(In reply to comment #4)
> In discussion, there were clearly a number of people who felt that the term
> ISSD was intended to mean what I meant by "static schema", that is, all the
> schema definitions available to the processor during static analysis.


I think the spec says that, I gave a trace in comment #3.


> I think there are a couple of difficulties with this. Firstly, it means that
> "import schema" loses any connection with the <xsd:import> element on which it
> was originally based; it can no longer be described as giving the query access
> to a particular set of component names in a particular namespace. If we want to
> do this we should probably say explicitly that "import schema" IS transitive,
> that is, it imports all the schema components in and referenced by the
> identified schema document, irrespective of their namespace, so that the user
> has some kind of predictability in knowing which names can be used in a query
> as a consequence of a given "import schema" declaration.


I think http://www.w3.org/TR/xquery/#dt-schema-import is completely vague about
what schema components are imported, and whether import schema is transitive or
not. Do you see clear language that says it is not transitive? This seems like
something worth fixing.

> Secondly, I think that it we adopt this wider interpretation of ISSD, then the
> contents of the ISSD become very variable from one implementation to another,

I think that's true for every single thing that is augmentable by an
implementation. But here is the interpretation the spec gives us:

# Default initial value: This is the initial value of the component if it is
not overridden or augmented by the implementation or by a query.

# Can be overwritten or augmented by implementation: Indicates whether an
XQuery implementation is allowed to replace the default initial value of the
component by a different, implementation-defined value and/or to augment the
default initial value by additional implementation-defined values.

# Can be overwritten or augmented by a query: Indicates whether a query is
allowed to replace and/or augment the initial value provided by default or by
the implementation. If so, indicates how this is accomplished (for example, by
a declaration in the prolog).

As long as the implementation documents how it augments the value, it's free to
do so. I don't think we should try to change this as a bug fix to a published
spec.

> I think it's actually useful to make a distinction between "the set of types
> that the schema processor knows about at analysis time" and "the set of types
> that the query is allowed to mention by name". It means that when you read the
> "import schema" declarations in the prolog, you know something about the
> module's dependencies, just as you do if you read the "import module"
> declarations.

We can make changes to the model for our type system in future versions of the
spec if we choose to, but please not as a bug fix to a published spec.

> Finally: the consistency constraints that are the subject of the original bug
> clearly apply only in the case of a processor that is doing static type
> inferencing. 

I'm not sure that I believe this. Suppose the data model instance and the ISSD
define the same name, but do so in two different ways. Wouldn't that affect
SequenceType Matching and casting in ways that our spec does not account for?

Jonathan


-- 
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 Wednesday, 30 July 2008 15:05:10 UTC