[Bug 5861] Elements with complex types should be allowed to have assertions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5861


C. M. Sperberg-McQueen <cmsmcq@w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@w3.org>  2008-09-09 01:28:44 ---
Thank you, Tony, for your comment.  Feedback from practitioners is
always helpful, and we are grateful for your time and interest.

The XML Schema Working Group has discussed your proposal at length,
and I took an action to summarize the upshot, with input from other WG
members.  I am delinquent not to have done so before now, but hope the
delay has not been unduly inconvenient for you.  [I should acknowledge
the assistance of my fellow WG members Fabio Vitali and Paolo
Marinelli of the University of Bologna in the preparation of this
response; any errors it contains are mine.]

I regret to say that while the Working Group has a certain sympathy
for your arguments, the consensus within the group was against making
the change you suggest and allowing assertions on element
declarations.  In the course of the discussion, three main arguments
were brought forward against the plan.

1) It seems to run counter to what the WG regards as an important
design principle distinguishing between element declarations and type
definitions. 

Basically, type definitions are meant to define the legal content of
elements, while element declarations provide the context for these
definitions. This is why element declarations allow the schema author
to specify only those constraints that do not affect what should and
what should not be considered legal INSIDE the element being declared;
that's the job of the type definition.  Occurrence constraints are an
example of this division of labor: they appear on element declarations
in the XML syntax, and they look outward, not inward. 

Clearly, assertions within element declarations would represent an
exception to the principle, since assertions limit the set of legal
instances of content within the element.


2) Second, you observe that the set of applicable assertions may vary
with context.  The WG doesn't disagree, algthough our instinct (in the
light of the design principle just outlined) is to say that that's
prima facie evidence that related but different types are being used
in the different contexts.

However one analyses the situation, the WG believes that workarounds
exist that address the scenarios you mentioned in a rather satisfying
way. For instance, in order to associate assertions to a specific
element declaration, it is always possible to use an anonymous type
definition deriving from the desired type and adding the additional
assertions.  

I believe your second paragraph is intended as a refutation in advance
of our suggestion, but I am not sure the refutation is successful.
You are right to observe that the workaround we suggest will involve
the use of local element declarations in the different places where
different assertions are required.  (Almost right, that is, because
one could simply use several different global element declarations
with different names; I assume that you pass that option over in
silence as undesirable for other reasons.)  But the solution you
propose, viz. attaching different assertions to the different contexts
by using different element declarations, will itself also involve the
use of different local element declarations -- or of global element
declarations with different names.  So I respectfully suggest that
your second paragraph does not succeed in making a case against this
workaround.


3) Finally, there is a practical consideration. The introduction of
the proposed amendment would represent a modification with a heavy
impact on the current state of the XSD 1.1 draft. Its ramifications
would require that we revisit a dismayingly large number of
well-established decisions (such as restriction is subsumption, unique
particle attribution, etc.) that would have to be re-discussed from
scratch. As a result, it would require a substantial workload by the
WG. Given the current status of Last Call Public Working Draft of XSD
1.1, and given the existence of workarounds, the WG believes there is
not enough time for further discussion of this proposal for the time
being.


Given the motivations discussed above, the end of the WG's discussion
was a decision to close this bug without further action.  The status
might be marked either as WORKS FOR ME or as WON'T FIX; the former
would reflect the Working Group's view that the association of
assertions with types and not with attributes is a design decision
correctly made, and not a bug.  But a case could be made that even if
one accepts that the decision was misguided and constitutes a bug, the
second and third arguments given above amount to arguments that the
bug is not fatal (there are workarounds) and that fixing it would be
more costly (in time and in risking the successful completion of the
spec before our charter expires) than not fixing it; the status could
thus as easily be set to WON'T FIX.  I am marking it as the latter.

I hope that the paragraphs above will show that the Working Group gave
serious attention to your comment, and persuade you to see the matter
as we do.  If they have done so, please indicate as much by changing
the status of this issue to CLOSED.  If you are not persuaded and wish
to continue the discussion or to appeal the decision to the Director,
please indicate this by changing the status to REOPENED.

If we don't hear from you in the next couple of weeks, we will take
your silence as indicating assent, and we'll change the status to
CLOSED.


-- 
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 Tuesday, 9 September 2008 01:29:18 UTC