- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Mar 2011 21:05:51 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11354 C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needsDrafting |needsAgreement Depends on| |12184 --- Comment #3 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-03-02 21:05:51 UTC --- I'm beginning to believe that the WG needs to re-open this issue because our resolution was based on an inaccurate premise. In particular, we were operating on the belief that the override transform is defined in such a way that eventually, after performing the transform for each document in the target set of a given override element, one would have a set of schema documents none of which contain any override elements. It would be these schema documents which are subject to the schema-document constraints. But as Michael Kay has pointed out in bug 12184, the override transformation is not guaranteed to eliminate all occurrences of the override element. On the contrary, it may increase the number of override elements, since it transforms every include element into an override element. This should not be a surprise, since it was made explicit in the design discussions for the override facility that the transform would turn cycles of includes into cycles of overrides. But the shorthand description that 'the semantics of override can be reduced to the semantics of include' (which is true, I think, as far as it goes) led the WG into the false belief that 'the override transform transforms all overrides into includes'. Since the transform as currently specified does not eliminate all override elements, we cannot as things stand plausibly eliminate override elements from the syntax overviews in the spec (which means that bug 11179 also needs to be revisited) or from the schema for schema documents. I think our options include at least: 1) Reverse our decision on this issue and bug 11179. Accept that override elements must be handled in the schema for schema documents, in syntax overviews, and in discussions of where elements can appear. Ensure that all constraints on schema documents make sense in the presence of override. 2) Respecify the override transform to change the way it propagates an override. In particular, make it guarantee that a simple-minded process of applying the transform will ultimately produce a set of documents without any override elements. The second option has the unhappy property that almost every time I look at it, it seems to be within reach, and every time I try to sketch the transformation required, I find that it either doesn't eliminate overrides after all, or that it fails to provide the functionality required by our resolution of bug 6021. 3) Forbid cycles in override and include. In the absence of cycles, there is an override-free set of schema documents corresponding to any override target set. For the reasons just given, I'm (unilaterally) changing the status of this issue from needsDrafting to needsAgreement, and marking it as dependent on bug 12184. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 2 March 2011 21:05:53 UTC