Re: Cross-references among included schema documents

"Michael Kay" <mhk@mhk.me.uk> writes:

> So you are telling me that the statement in 3.15.3, "For a ·QName· to
> resolve to a schema component of a specified kind all of the following must
> be true:" is wrong? The first condition below that statement reads: "That
> component is a member of the value of the appropriate property of the
> schema...". Is this condition completely wrong, should I ignore it totally,
> or does it have some residual meaning? 

It means exactly what it says.  It's just that the resolution to which
it applies may be _delayed_, per the quotes you and I have exchanged.

> Does this also mean, for example, that if P imports Q and Q imports R, that
> a QName in P can resolve to a component defined in R? And perhaps that a
> QName in R can resolve to a component defined in P? Are there any
> restrictions at all?

Depends on whether the QName is in P's target namespace.  If so, yes.
If not, no, because of the _additional_ requirement wrt 'external'
references and import.  Import has this requirement, include does not.

> This would mean that if I implement a schema cache in which R is cached, the
> names in R can resolve differently depending on who imports it.

I don't understand what you're getting at here, sorry.

> The problem I have with the para from 4.2.1 is the phrase "during schema
> construction". Is there any point at which I can decide schema construction
> is complete,

The only thing the REC _requires_ you to do is try to dereference
schema locs in xs:include.  You can stop after that, ignoring all
schema locs in xs:import and instances, if you like (your users will
complain, but you'll be conformant :-).  At that point you know what
references are unresolved, definitively.

> or is it not possible to report unresolved references in a
> schema until you actually see an xsi:schemaLocation attribute in an instance
> document, at which point you know the full set of schema components
> available?

That's a more helpful approach, yes.  But, and it's a big 'but', the
REC doesn't classify unresolved QNames as an error -- see below, so
such reporting is at best advisory.

> This would mean that none of the more complex schema consistency
> constraints can be checked in advance, which would surely be a bad
> thing.

"No harm, no foul" is the XML Schema principle, inherited from DTDs.
Components with unresolved QNames in, which are not needed for
instance validation, _must not_ break validation.  The analogy is with

<!DOCTYPE foo
<!ELEMENT foo (a?)>
]>
<foo/>

A conformant XML validator must _not_ report any error here, even
though there is no declaration for 'a'.

> This now leaves me the problem of deciding whether to implement what the
> spec says, or what its authors say that it should have said. (I'm
> implementing 1.0, not 1.1!)

I _hope_ I'm telling you what it actually says.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Monday, 27 September 2004 09:46:58 UTC