W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

[Bug 5507] Symbol spaces need clearer description

From: <bugzilla@wiggum.w3.org>
Date: Wed, 27 Feb 2008 18:22:42 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1JUQvS-0008Dl-9r@wiggum.w3.org>


           Summary: Symbol spaces need clearer description
           Product: XML Schema
           Version: 1.0/1.1 both
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: cmsmcq@w3.org
         QAContact: www-xml-schema-comments@w3.org

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

(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

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

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.
Received on Wednesday, 27 February 2008 18:22:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:07 UTC