8444 2009-12-07 10:50:53 +0000 Limited Extensibility 2010-11-10 17:15:53 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows XP CLOSED FIXED P2 normal --- 1 shropshire David_E3 cmsmcq mike www-xml-schema-comments oldest_to_newest 29940 0 shropshire 2009-12-07 10:50:53 +0000 Hopefully this has been addressed already. Problems with XML schema regarding extensibility. unique particle attribution Say you are an application developer, and you are using XML Schema to constrain Web Services XML docs that are used in communications with other apps not under your control. These XML docs have a hierarchy like: 1st Generation --------------- xa xab xad xsd:any (optional - placeholder for future extension, 1st Generation apps will not use this element) and you want to insert a new node under xa without breaking apps using the old structure (1st generation apps). 2nd Generation -------------- xa xab xad xae (new optional node) In your 1st generation app, since you put xsd:any after xad, 1st generation apps will allow the new xae optional element. This way, you will be able to understand stuff the old apps send you (they won't put anything in xsd:any) and they will understand (by ignoring xae) stuff you send them. The problem arises when you want to add another element in a 3rd app. 3rd Generation -------------- xa xab xad xae (optional) xaf (optional) Because xae was optional, xsd:any cannot be placed after xae. Thus 3rd generation apps (with xae and xaf) can communicate with 1st generation apps but cannot send to 2nd generation apps (2nd generation and 1st generation apps may send to 1, 2, and 3 and receive from 1 and 2). 1 may receive from 1, 2, and 3 1 may send to 1, 2, and 3 2 may receive from 1 and 2 2 may send to 1, 2, and 3 3 may receive from 1, 2, and 3 3 may send to 1 and 3 Solution --------- SHOULD allow optional elements to be placed before an xsd:any optional element. 29941 1 mike 2009-12-07 11:30:58 +0000 Firstly, I assume that in the "1st Generation" schema, the xsd:any has maxOccurs="unbounded" (that is, it allows multiple elements in this position). If it only allows one element, then your "3rd Generation" would definitely be invalid. If your "2nd Generation" schema wants to allow further extensibility, then it can be written as: 2nd Generation -------------- xa xab xad xae (new optional node) xsd:any which seems to be exactly what you are asking for. I'm not sure why you think this isn't allowed. The relaxation of UPA in XSD 1.1 (which allows wildcard particles to overlap element particles) was introduced for this reason. Is there something here I have missed? 29955 2 cmsmcq 2009-12-07 14:53:31 +0000 As Michael Kay has observed, the reformulation of the Unique Particle Attribution in 1.1 (the so-called 'weakened wildcard' change) does make it legal for a wildcard particle to compete with an element particle in a content model, and thus for an optional element particle to precede a wildcard in a sequence. In 1.0 it is not allowed for wildcard and element particles to compete, and so an optional element particle cannot be followed in a sequence by a wildcard. So in 1.0 the solution to the problem needs to take place on a different layer of the design: if you don't want first-generation apps to break when they see content that is not valid against the first-generation schema, then write them to accept invalid input and do the best they can with it. (HTML has prospered fairly well with this recipe.) Or rewrite the illegal content model with an equivalent content model that is legal. In the example given, the content models desired for the second and third generation apps (the ones shown, plus an additional repeating wildcard) seem at first glance to accept the same language as the content model given for the first-generation app. The differences thus appear to have at most a rhetorical or documentary function. Am I missing something? The Unique Particle Attribution constraint certainly makes some regular languages inexpressible, and I continue to believe that it should never have been made part of XSD and that it should be eliminated at the first opportunity. But the simple wildcard problems described here and in some other discussions of versioning don't seem to involve languages that cannot be expressed in XSD 1.0 content models; they involve, as far as I can see, only a dissatisfaction with the expression prescribed for those languages by XSD 1.0. 29957 3 mike 2009-12-07 15:07:21 +0000 >In the example given, the content models desired for the second and third generation apps (the ones shown, plus an additional repeating wildcard) seem at first glance to accept the same language as the content model given for the first-generation app. But the element particles for xae and xaf can specify a type that is more restrictive than the type allowed by the wildcard. 29960 4 shropshire 2009-12-07 15:33:11 +0000 (In reply to comment #3) > >In the example given, the content models desired for the second and third generation apps (the ones shown, plus an additional repeating wildcard) seem at first glance to accept the same language as the content model given for the first-generation app. > But the element particles for xae and xaf can specify a type that is more > restrictive than the type allowed by the wildcard. 1st, 2nd, and 3rd generation apps will all accept docs generated by 1st generation apps. However, a 2nd generation app will not accept this doc from a 3rd generation app: xa xab xad xae xaf because a 2nd generation app does not accept anything after xae. Apparently, XSD 1.1 allows xsd:any to be used after an optional element, so this problem of not being able to add on optional elements without breaking earlier versions of the schema can be resolved. I have marked the bug report resolved. 42360 5 David_E3 2010-11-10 17:14:44 +0000 The WG reported this bug as FIXED on 2009-11-20. We are closing this bug as requiring no futher work. If there are issues remaining, you can reopen this bug and enter a comment to indicate the problem. Thanks very much for the feedback. 42361 6 David_E3 2010-11-10 17:15:53 +0000 The WG reported this bug as FIXED on 2009-12-07. We are closing this bug as requiring no futher work. If there are issues remaining, you can reopen this bug and enter a comment to indicate the problem. Thanks very much for the feedback.