- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 27 Feb 2008 18:22:42 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5507 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 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.
Received on Wednesday, 27 February 2008 18:22:57 UTC