+++ This bug was initially created as a clone of Bug #5507 +++

[Bug 5507 will track this issue for XSD 1.1, this bug for 1.0.]

The discussion of bug 5157 suggests that there are some aspects of
symbol spaces which could usefully be made clearer in the spec.  Among
them:

(1) Symbol spaces contain expanded names (namespace name + local name
pairs), not just local names.

(2) Symbol spaces are used to enforce uniqueness constraints: no two
components can have the same name within the same symbol space, so
each name within a symbol space uniquely denotes a component.

(3) Symbol spaces are also relevant to QName resolution, although not
mentioned explicitly in the rules for it.  The resolution of QName
references to components involves looking for a component with the
given expanded name, within the appropriate symbol space.

(4) Symbol spaces are NOT used, however, in attributing element or
attribute instances to particular particles and declarations in the
schema.  An element with a given expanded name will match (other
conditions being propitious) any element declaration with that
expanded name in the content model; it does not matter whether that
element declaration is global or local.  Simiilarly also for
attributes.

Proposition (1) appears to contradict the current text of section 2.5,
which does its best to suggest that symbol spaces are somehow situated
within target namespaces.  It says, for example:

    There is a single distinct symbol space within a given target
    namespace for each kind of definition and declaration component
    ...

But this description contradicts the usage of the term 'symbol space'
in the spec.  Section 3.1.1, for example, refers to

    ... equality of names (including target namespaces) within symbol
    spaces.
  
If equality of names, including equality of target namespaces, can be
tested for 'within' symbol spaces, then there cannot be distinct
symbol spaces for top-level elements in distinct target namespaces.

Another example:  section 3.11.1 says

    Each constraint declaration has a name, which exists in a single
    symbol space for constraints. 

If there is a single symbol space for names of identity constraints, 
then it cannot be located within any single target namespace.

So: first, section 2.5 needs to be corrected to agree with the spec's
actual usage, and second, if possible the relation of symbol spaces to
various name matching tasks (QName resolution, instance attribution,
etc.) should be made clearer.

This problem exists both in 1.1 and in 1.0.