[Bug 6513] [XQuery] inconsistent terminology in definition of derives-from()

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





--- Comment #13 from Jonathan Robie <jonathan.robie@redhat.com>  2009-03-17 13:04:33 ---
(In reply to comment #12)
> >To me, the open question is whether the assembled schema is imported, after all schema import, include, redefine, etc. has been done. 
> 
> I think it's best to avoid the verb "imported" unless it's very precisely
> defined. The "import schema" declaration certainly causes the instantiation of
> a schema (=set of schema components) that many contain components in many
> namespaces, and the question is whether the ISSD of the module should contain
> the names of all those components, or only those names that are in the
> namespace that is the target of the import. The analogy with xs:import and with
> "import module" suggests that it should only be the names in the target
> namespace.

Actually, this is now clear. We resolved bug 5738
(w3c-xml-query-wg/2009Feb/0098.html):

ACTION: Jonathan to add a non-normative note clarifying that the
assembled schema is imported. Goal: 2ed. Mark bug as resolved.


> >But if the answer were "no", this would not be a statically known type in M1 as defined in the XQuery specification. It's not in the ISSD of the module. I don't think the specification is ambiguous on this.
> 
> The specification doesn't actually use the phrase "statically known type", let
> alone define it. In 2.5.4 it uses "known type" as a synonym for "type present
> in the ISSD", and the confusion/ambiguity in this bug report arises because of
> the tacit acknowledgement in the text that the processor might also know about
> types that are not in the ISSD.

As I said in an earlier comment, I think that we should use the term
"statically known types" rather than just "known types".

There are two well defined ways for a processor to make use of such types:

- static typing extensions for statically known types
- the "winged horse" for dynamically known types

How they do that is implementation defined. We don't have to define that.

> Meanwhile, as highlighted in bug #5738, section 2.2.5 imposes a constraint that
> if type T is in the ISSD, then all types derived by extension from T, if they
> appear in a run-time instance, must also be in the ISSD. This is too strong;
> the section should recognize, as 2.5.4 does, that the processor may know about
> things even though they are not in the ISSD. (It is also too strong because a
> processor that doesn't know about all types derived by extension can function
> perfectly well provided it avoids making inferences on the assumption that it
> does know about all such types.)

I think you are saying that your implementation wants a static typing extension
to allow extended types that are not imported into a given module, because you
have a data dictionary of some sort that you know the document conforms to. I
think you can do that by documenting it as a static typing extension. I don't
think we have to change the spec to make that possible.

In your static typing extension, there are statically known types that are not
in the ISSD, they are used for static inferences not defined in our
specification.


-- 
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 Tuesday, 17 March 2009 13:04:42 UTC