This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 3.16.3, the Schema Representation Constraint: QName Interpretation reads in part: In the absence of the [in-scope namespaces] property in the infoset for the schema document in question, processors must reconstruct equivalent information as necessary, using the [namespace attributes] of the containing element information item and its ancestors. This formulation reflects a fundamental misunderstanding of the nature of information sets, which we should neither retain in our spec nor encourage in others. The [in-scope namespaces] property and the [namespace attributes] property of the basic infoset are not names for different fields in a data structure; the former is merely a different name for a subset of the information present in the latter. It is not only not necessary to "reconstruct the equivalent information", if [namespace attributes] is present, but it is not possible for the information of [namespace attributes] to be present without the information of [in-scope namespaces] being present. The existing text would make sense if the infoset spec were the description of a data structure, or of an API. It is neither. The paragraph in question should be deleted.
On its telcon today, the Working Group discussed this and other recently opened issues in the issues database and concluded (not without some pangs of regret) that for scheduling reasons it is not feasible for us to resolve this issue, or any of the others in the group, before we go to Last Call. On whether the issue / proposal discussed here is worth pursuing or not, the WG has taken no formal decision. Accordingly I am closing this issue with a disposition of LATER, not WONTFIX. That means the Working Group believes that the issue may be resolved in some future version of the spec, and encourages whatever Working Groups are responsible for future versions of the spec to consider this issue at an appropriate time. (If this bug relates both to 1.0 and 1.1, this resolution applies only to 1.1 and leaves undetermined how to handle it vis-a-vis 1.0.)