Re: In-scope schema components -- tricky question

The original way we conceived doing this in XSLT became a little fuzzy over time, distorted largely by XPath/XQuery people having different ideas, not all of them clearly articulated.

The way I originally understood the XSLT model was:

(a) there’s a set of schema components known to the system. For example, if someone submits a source document that has been validated against a schema, its nodes will contain references to the schema components against which they were validated. Some of these components will only become known at run-time.

(b) there’s a subset of these schema components which are known at stylesheet compile time. These are the components that have been explicitly (or transitively) imported using xsl:import-schema. In XSLT 2.0 this set is the same for all stylesheet modules; this changes in 3.0 with independent compilation of packages.

When you refer to a schema component statically by name (e.g. in an “as” or “instance of” construct) then the component has to be in set (b). But when you invoke validation, the only requirement is that it is in set (a).

Section 2.9 (I’m using the XSLT 3.0 draft) says: [Definition: The schema components that may be referenced by name in a stylesheet are referred to as the in-scope schema components. This set is the same throughout all the modules of a stylesheet.] 

XPath (I’m using 3.1) is reasonably aligned with this: [Definition: In-scope schema definitions. This is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during static analysis of an expression.]

(Immediately we hit difficulties. The XSLT definition needs changing for 3.0 packages).


> 
>  1) Are "[t]he components in the schema constructed from the
>     synthetic schema document" any different from the "in-scope
>     schema components"?  I suppose not below, and call that the ISSC.

In my original concept, yes, but at some stage we allowed the ISSC to be augmented with schema components declared in some other way, e.g. through the processor API.
> 
>  2) Stipulate that, as allowed, when validating constructed elements,
>     a schema-aware XSLT implementation does exploit some schema
>     location hints as a matter of course.
> 
>      2a) If, in exploiting some hint, it encounters a definition for
>          e.g. a type whose QName already occurs as the name of a type
>          in the ISSC, must it throw an error?  Does it say this in
>          the XSLT spec and I missed it?

I’m not immediately sure where to find chapter and verse, but the basic model is that the schema (both (a) and (b)) must be consistent, e.g. you can’t have two different components with the same name, and we say that the consequences of having an inconsistent schema are completely unpredictable - it’s a bit like supplying an input document that doesn’t conform to the constraints defined in XDM. The system might or might not notice the inconsistency, and either way, it can give a neat error, crash, or give incorrect results.
> 
>      2b) Are the components it finds via hints then added to the
>          ISSC?  That is, in subsequent validation of any kind, for
>          example in the type signature of a function, are those
>          components available?

No, nothing that happens at run time can affect what happens at compile time.
> 
Michael Kay
Saxonica

Received on Sunday, 14 June 2015 19:49:12 UTC