[Bug 13674] [XQ30] schema-element() types behave differently in different modules.

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

--- Comment #13 from Jonathan Robie <jonathan.robie@gmail.com> 2011-10-07 15:09:48 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #7)
> > > Reopening because I don't think the issue has been adequately addressed.
> > 
> > What is the issue? Could you please clearly state what problem needs to be
> > solved?
> 
> It is explained in great detail in the initial bug report, and is then
> generalised to a wider problem in the first paragraph of comment #1. In
> summary, different modules can have different schemas and this means that an
> element validated with type T in one module can be invalid against type T in
> another module, which violates type soundness. 

I believe the following text - which already exists - says that types that are
known in one module must be consistent with types known in another module, and
that types known in a module must be consistent with types in an instance that
it queries:

<quote>
An XQuery 3.0 implementation must be able to determine relationships among the
types in type annotations in an XDM instance and the types in the in-scope
schema definitions (ISSD). An XQuery 3.0 implementation must be able to
determine relationships among the types in ISSDs used in different modules of
the same query.
</quote>

> My proposal in comment #7 is to
> "fix" this by strengthening the existing rules requiring the schemas used by
> different modules to be consistent with each other.

I think your proposal does more than that, it would require all modules to use
the same schema definitions. That's something we've never required in the past,
and it would significantly change behavior. For instance, with your proposal, I
can't have a module that imports no schemas so that I can do some things with
weaker typing assumptions. That's something that's very useful to do sometimes,
e.g. when dealing with different kinds of HTML I may want one module to make
very few assumptions so I can read various dialects, but another module might
want to import a specific schema so I can create valid HTML of some kind and
work with HTML known to be a valid instance of that kind.

So I don't think it's currently broken, and I think that your proposal would
break it.

-- 
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 Friday, 7 October 2011 15:09:51 UTC