6561 2009-02-11 22:44:41 +0000 Type Substitutable in Restriction 2009-04-18 02:23:44 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows XP RESOLVED FIXED resolved P2 minor CR 1 hrennau David_E3 cmsmcq www-xml-schema-comments oldest_to_newest 23660 0 hrennau 2009-02-11 22:44:41 +0000 In section 3.4.4.5 Conditional Type Substitutable in Restriction, clause 2.1 surprises me - it implies that an element E may have a context-determined type table in xs:anyType. Section 3.4.4.1, definition of context-determined type table, clauses 1 and 3.1 seem to exclude this: "If T is xs:anyType, then E has no context-determined type table in T". With kind regards - Hans-Juergen Rennau 23730 1 sandygao 2009-02-13 19:53:22 +0000 Clause 1.2 in 3.4.4.1 may apply for xs:anyType (remember that anyType has a lax wildcard), in which case clause 3 doesn't apply, and E could have a context-determined typed table within anyType. But clause 1.2 seems to have the unfortunate issue that it applies even for skip wildcards, which may not be intentional. 23842 2 David_E3 2009-02-20 17:24:01 +0000 The WG discussed, and agrees that Sandy's analysis in commnt 1 is correct. The WG could not agree on whether to change clause 1.2 by excluding skip wildcards, however. The WG decided to close this bug as LATER, based on Sandy's analysis, and internal lack of consensus on how to do better. 23850 3 sandygao 2009-02-21 14:26:57 +0000 Some new information to consider. In section 3.4.4.1 where "context-determined type table" is defined, we have the following note: "Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if E ·matches· more than one such declaration D, there will be just one ·context-determined type table·." If we jump to EDC in 3.8.6.3, you can see that bullet 2.1 only considers strict and lax wildcards. So now we have a contradiction: EDC doesn't guarantee consistency for type tables when skip wildcards are involved, but CDTT definition depends on that. Somewhat repeating what was said earlier: the whole 1.0 spec and the rest of 1.1 spec were written with the view that if an element/attribute information itme matches a "skip" wildcard, then no additional constraints are imposed on top of "well-formed XML". Why should CDTT be treated differently? Whether we make this "skip" change or not, consider: <schema ...> <element name="table" type="htmlTable"> <alternative .../> <alternative .../> </element> <complexType ...> <sequence> <element name="table" type="furnitureTable"/> It's almost guaranteed that the complex type would not have a valid instance, because we will apply the type table from the global element declaration to instances of the local one. This seems to limit the usefulness of type alternatives. Note that in complex type restriction, we made derivation from xs:anyType magical (clause 2.1 in "Derivation Valid (Restriction, Complex)"). To be consistent with that, maybe anyType really shouldn't provide any CDTT as suggested by the original bug report? (CDTT is only used in complex type restriction.) 23893 4 cmsmcq 2009-02-23 23:31:11 +0000 In comment #3, Sandy Gao writes: So now we have a contradiction Can you expound the contradiction a bit further? I am not seeing a clear contradiction here. I think you are saying that we can construct a schema in which a given element instance has more than one context-determined type table. If this is true, I think we do have a problem. Is there an example schema that illustrates the problem? It's not clear to me that such a schema can be constructed. 23920 5 636 cmsmcq 2009-02-25 03:36:45 +0000 Created attachment 636 Alloy model of contextual determination of type table A further note here on the quest for an example in which there is a type which for which the mapping from QNames (or element instances) to context-determined type tables is not a function. I continue unable to construct such an example. I attach an Alloy model of this part of the spec. I have used this model to try to findt a schema in which there is some complex type which does not uniquely determine a context-determined type table for each possible QName. The Alloy Analyzer has searched all models with seven or fewer complex types and seven or fewer element declarations, without finding a case of a context-determined type table which is not uniquely determined. While it is suggestive, Alloy's failure to find a counter-example is not, of course, conclusive. There may be counter-examples in larger schemas. Or the Alloy model could be faulty in its description of XSD's rules. Corrections and examples of problematic schemas welcome. My experiments with this model have led me to believe it might be more nearly correct to rephrase the note which currently reads Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if E matches more than one such declaration D, there will be just one context-determined type table. to make it read Note: The definition just given, together with the constraint Element Declarations Consistent (§3.8.6.3) and the rule ensuring that no two top-level element declarations have the same name, ensures that even if E matches more than one such declaration D, there will be just one context-determined type table. I doubt, however, that the increased correctness is worth making the note wordier and harder to follow. 23969 6 hrennau 2009-02-27 00:13:11 +0000 Intuitively, I share Sandy Gao's unease concerning the situation that a) a skip wildcard may play a role in determining the context-determined type table; b) xs:anyType is a possible source of a context-determined type table. The stated contradiction, however - "EDC doesn't guarantee consistency for type tables when skip wildcards are involved, but CDTT definition depends on that." does not exist in my opinion, because the CDTT definition does not at all depend on EDC's second part, the part dealing with wildcards. This follows from CDTT's wording of clause 1: "Let D be an Element Declaration matched by E, given by the first case among the following which applies." "given by the first case" means: a) if there is at least one matching element declaration, clause 1.2 becomes irrelevant and wildcard matches are ignored b) if there are only wildcard matches, there can be only one matching top level element declaration So the EDC is only relevant if clause 1.1 applies, and it is only used to exclude inconsistencies between matching element declarations. In conclusion, I suggest a microscopic modification of 3.4.4.1/note#1: <actual> Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if E ·matches· more than one such declaration D, there will be just one ·context-determined type table·. </actual> <proposed> Note: The constraint Element Declarations Consistent (§3.8.6.3) ensures that even if clause 1.1 applies and E ·matches· more than one such declaration D, there will be just one ·context-determined type table·. </proposed> With kind regards - Hans-Juergen Rennau 23971 7 sandygao 2009-02-27 02:38:34 +0000 I think both of you are correct in that the contradiction doesn't exist. I missed the phrase "the first case" in clause 1 of the CDTT definition. (Because of EDC, I naively thought it was not necessary to use "the first case", as EDC should/would guarantee that 1.1 and 1.2 will produce the same result.) So I'm ready to withdraw the first half of my comment #3, given that there is no new information. I'm leaving this bug as "reopened", because I believe the process is that once you submit a comment, you can't just take it back. Also it's not clear to me whether the WG needs/wants to take an explicit action on the second half of comment #3 (about anyType). 24003 8 hrennau 2009-03-02 07:08:44 +0000 (In reply to comment #7) > I think both of you are correct in that the contradiction doesn't exist. I > missed the phrase "the first case" in clause 1 of the CDTT definition. > > (Because of EDC, I naively thought it was not necessary to use "the first > case", as EDC should/would guarantee that 1.1 and 1.2 will produce the same > result.) > > So I'm ready to withdraw the first half of my comment #3, given that there is > no new information. I'm leaving this bug as "reopened", because I believe the > process is that once you submit a comment, you can't just take it back. > > Also it's not clear to me whether the WG needs/wants to take an explicit action > on the second half of comment #3 (about anyType). > By now I am convinced that you are right in your intuition that allowing skip wildcards to determine a CDTT might introduce inconsistency. A simple example demonstrates this. Consider this schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="e2" type="t2"/> <xs:element name="b" type="xs:integer"/> <xs:complexType name="t1"> <xs:sequence> <xs:element name="a" type="xs:string"/> <xs:any processContents="skip"/> </xs:sequence> </xs:complexType> <xs:complexType name="t2"> <xs:complexContent> <xs:extension base="t1"> <xs:sequence> <xs:element name="b" type="xs:date"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema> Then any element validated against element declaration e2 will be invalid, because applying "Conditional Type Substitutable in Restriction" to child element b (with T=t2, B=t1) yields: ST = xs:date SB = xs:integer that is, ST != SB, a violation of the constraint. If the global and the local element declaration indeed contained type tables (<alternative> children) the problem could be removed by ignoring skip wildcards when determining the CDTT, as you suggested (that is, by modifying clause 1.2 of the CDTT definition). However, if global and local declaration do not contain type tables - as was the case in the example - the CDTTs are "effective type tables" (constructed from {type definition}), and then the wildcard's {process contents} becomes irrelevant, as "3.8.6.3 Element Declarations Consistent" does not safeguard against differences of {type definition} in the absence of {type table}. To address this issue, I am going to open a separate bug report. 24008 9 cmsmcq 2009-03-02 16:42:02 +0000 Perhaps I am just too dim to understand it, but I don't see what contradiciton arises from the example in comment #8. If someone who has looked into the example in greater detail can put it in terms of "For this example, rule xyz entails that A, and rule vwx entails that not(A)", I'd be grateful. 24009 10 sandygao 2009-03-02 18:14:02 +0000 FYI. It seems that bug 6644 was opened for the example in comment #8. 24012 11 hrennau 2009-03-03 07:37:45 +0000 (In reply to comment #9) > Perhaps I am just too dim to understand it, but I don't see what contradiciton > arises from the example in comment #8. If someone who has looked into the > example in greater detail can put it in terms of "For this example, rule xyz > entails that A, and rule vwx entails that not(A)", I'd be grateful. > Before trying to express the problem in a more general way I want to clarify a point on which we may disagree. The matter *is* important because constraint 3.4.4.5 can destroy the validity of a document which is valid according to the conviction of 9 out of 10 experienced users (if not 999 out of 1000). Imagine a little ten-liner in the depth of a large project, which is called in the course of vital system operations and which - under rare yet conceivable circumstances - produces a null pointer exception. The ten-liner is given in three parts - constraint 3.4.4.5 (Conditional Type Substitutable in Restriction), the definition of CDTT and constraint 3.8.6.3 (Element Declarations Consistent). The null pointer exception consists in rendering a perfectly healthy document invalid. The rare but conceivable conditions are these: - a complex type T overrides a global Element Declaration by a local one (call its name E) - T is derived from another type B whose content model does not reference element E (so T either adds E as part of an extension, or narrows down a wildcard to E as part of a restriction) - B's content type contains a wildcard matched by E This constellation seems to me ordinary. Yet chances are that the validity of any element validated against T will be destroyed if it has a child E! This is because constraint 3.4.4.5 compares the type associated with E (according to the CDTTs) in B on the one hand, and in T on the other hand. If T extends B, these types even have to be equal - which probably will not be the case, as T chose to override the global element declaration. You asked about the "contradictions". Contradiction 1: Constraint 3.8.6.3 (Element Declarations Consistent) explicitly states that strict and lax wildcards restrict the freedom of using a type table in a locally redeclared element; the constraint implies that skip wildcards do not restrict this freedom. But constraint 3.4.4.5 means that skip wildcards do restrict the freedom! The difference is esoteric, but it may decide who will have a conversation with the boss: a strict or lax wildcard causes a schema error detected when processing 3.8.6.3, while a skip wildcard causes an instance document invalidity, detected when processing 3.4.4.5. Contradiction 2: Constraint 3.4.4.5 is meant (I believe) to ensure that the possibility of redefining type tables within a derivation chain does not compromise the concept of restriction, that is, the principle that any instance valid against the restricted type is valid against the base type. The effect however is introducing invalidity in cases where type tables are not even used and the "restriction principle" is not at all threatened. This is a contradiction to common sense. By the way: the present state of our ten-liner means that documents valid according to schema 1.0 become invalid according to schema 1.1. You discourage me from giving a further example. But I think I might present *real world examples* where nothing looks eccentric. 24542 12 sandygao 2009-04-03 17:29:14 +0000 During its 2009-04-03 telecon, the schema WG adopted a proposal to address this issue. The proposal can be found at (member-only): http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090313.html#anchor6561 Changes include: 1. Do not consider "skip" wildcards in computing context-determined type tables. 2. xs:anyType does *not* define any context-determined type table. With these changes, the WG believes that the issue raised in this bug report is fully addressed. I'm marking this RESOLVED accordingly. Hans-Juergen, as the persons who opened and reopened this issue, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent. 24751 13 hrennau 2009-04-15 22:07:26 +0000 Thank you for tackling this issue - I am content with the outcome. If I reopen this bug, it is only to draw your attention to a couple of editorial details: a) In 3.4.4.5 "Conditional Type Substitutable in Restriction", clause 2.1 should be removed (as B cannot any more be xs:anyType)- otherwise, this clause would definitely confuse. b) Perhaps 3.4.4.5 "Conditional Type Substitutable in Restriction" should be renamed, as it deals with extension too. (In reply to comment #12) > During its 2009-04-03 telecon, the schema WG adopted a proposal to address this > issue. > > The proposal can be found at (member-only): > > http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090313.html#anchor6561 > > Changes include: > 1. Do not consider "skip" wildcards in computing context-determined type > tables. > 2. xs:anyType does *not* define any context-determined type table. > > With these changes, the WG believes that the issue raised in this bug report is > fully addressed. I'm marking this RESOLVED accordingly. > > Hans-Juergen, as the persons who opened and reopened this issue, if you would > indicate your concurrence with or dissent from the WG's disposition of the > comment by closing or reopening the issue, we'll be grateful. If we don't hear > from you in the next two weeks, we'll assume that silence implies consent. > 24817 14 cmsmcq 2009-04-18 02:23:44 +0000 Thank you for pointing out these residual editorial problems. They have now been fixed (and a reference to clause 2.1 of Conditional Type Substitutable from elsewhere has also been suppressed, since the clause is gone). Those with W3C member access can see the change integrated into the status quo text at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html (member-only link) -- or at least, they will when the upload completes. Accordingly, I'm closing this issue as fixed. Thank you again for your interest in the spec and your comments. 636 2009-02-25 03:36:45 +0000 2009-02-25 03:36:45 +0000 Alloy model of contextual determination of type table ctt.als text/plain 10336 cmsmcq bW9kdWxlIHhzZGV4eC9jdHQKLy8gU2ltcGxlIGNoYXJhY3Rlcml6YXRpb24gb2YgY29udGV4dC1k ZXRlcm1pbmVkIHR5cGUgdGFibGVzIGluIFhTRCAxLjEKCi8qCiogQ29weXJpZ2h0IChjKSAyMDA5 IEJsYWNrIE1lc2EgVGVjaG5vbG9naWVzIExMQwoqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgoqIFJl ZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3IK KiB3aXRob3V0IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBm b2xsb3dpbmcKKiBjb25kaXRpb25zIGFyZSBtZXQ6CgoqICAgICAqIFJlZGlzdHJpYnV0aW9ucyBv ZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUKKiAgICAgICBjb3B5cmlnaHQgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZwoqICAgICAgIGRp c2NsYWltZXIuCgoqICAgICAqIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJl cHJvZHVjZSB0aGUgYWJvdmUKKiAgICAgICBjb3B5cmlnaHQgbm90aWNlLCB0aGlzIGxpc3Qgb2Yg Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZwoqICAgICAgIGRpc2NsYWltZXIgaW4gdGhlIGRv Y3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscwoqICAgICAgIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KCiogICAgICogTmVpdGhlciB0aGUgbmFtZSBvZiBCbGFjayBNZXNh IFRlY2hub2xvZ2llcyBMTEMgbm9yIHRoZQoqICAgICAgIG5hbWVzIG9mIGl0cyBjb250cmlidXRv cnMgbWF5IGJlIHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlCiogICAgICAgcHJvZHVjdHMgZGVy aXZlZCBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvcgoqICAgICAgIHdy aXR0ZW4gcGVybWlzc2lvbi4KCiogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBCTEFDSyBN RVNBIFRFQ0hOT0xPR0lFUyBMTEMgJydBUwoqIElTJycgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCiogTElNSVRFRCBUTywgVEhFIElNUExJ RUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5ECiogRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UCiogU0hBTEwgQkxBQ0sg TUVTQSBURUNITk9MT0dJRVMgTExDIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwKKiBJTkRJUkVD VCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCiogREFN QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GCiogU1VC U1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7 IE9SCiogQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRI RU9SWSBPRgoqIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElU WSwgT1IgVE9SVAoqIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcg SU4gQU5ZIFdBWSBPVVQgT0YKKiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURW SVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKiBTVUNIIERBTUFHRS4gIAoKKi8KCi8vIFJldmlz aW9uczoKLy8gMjAwOS0wMi0yMyA6IENNU01jUSA6IG1hZGUgZmlsZQoKLy8gRmlyc3QsIHNvbWUg c2lnbmF0dXJlcyBkZXNjcmliaW5nIHNvbWUga2luZHMgb2Ygb2JqZWN0cyB3ZQovLyBkb24ndCB3 YW50IHRvIG1vZGVsIGluIGRldGFpbC4KCi8vIHFuIDogZXhwYW5kZWQgbmFtZSAoYSBRTmFtZSB2 YWx1ZSkKc2lnIHFuIHt9IAoKLy8gdHQgOiBhIHR5cGUgdGFibGUuICBNYXkgZXh0ZW5kIG9uZSBv ciBtb3JlIG90aGVyIHR5cGUgdGFibGVzLgovLyBCdXQgd2UgZG9uJ3QgYWN0dWFsbHkgbmVlZCB0 byBtb2RlbCB0eXBlIHRhYmxlIGV4dGVuc2lvbiBoZXJlLgpzaWcgdHQgewogIC8vIGV4dGVuc2lv bl9vZiA6IHNldCB0dAp9IApzaWcgY29uc3RydWN0ZWRfdHQgZXh0ZW5kcyB0dCB7CiAgZGVmYXVs dF90eXBlIDogVHlwZURlZgp9ewogIC8vIGVzdGFibGlzaCB0aGF0IGVhY2ggY29uc3RydWN0ZWQg dHlwZSB0YWJsZSBpcyB1bmlxdWUKICBhbGwgVCA6IGNvbnN0cnVjdGVkX3R0IHwgCiAgICBkZWZh dWx0X3R5cGUgPSBULkBkZWZhdWx0X3R5cGUgPT4gVCA9IHRoaXMKfQovKiB9ewogIC8vIGNvbnN0 cnVjdGVkIHR5cGUgdGFibGVzIGRvbid0IGV4dGVuZCBhbnl0aGluZwogICNleHRlbnNpb25fb2Yg PSAwCn0gKi8KCi8vIGt3OiAganVzdCBhIGNvbnZlbmllbmNlIHNpZ25hdHVyZSB0byBhbGxvdyB1 cyB0byB0aGluayBvZgovLyBzb21lIHRoaW5ncyBhcyBrZXl3b3JkIHZhbHVlcwphYnN0cmFjdCBz aWcga3cge30gCmxvbmUgc2lnIGt3R2xvYmFsIGV4dGVuZHMga3cge30KbG9uZSBzaWcga3dTdHJp Y3QgZXh0ZW5kcyBrdyB7fQpsb25lIHNpZyBrd0xheCBleHRlbmRzIGt3IHt9CmxvbmUgc2lnIGt3 U2tpcCBleHRlbmRzIGt3IHt9CgovLyBTZWNvbmQsIGVsZW1lbnQgZGVjbGFyYXRpb25zIGFuZCB3 aWxkY2FyZHMuCgovLyBFbGVtZW50IGRlY2xhcmF0aW9ucyBoYXZlIGEgbmFtZSwgbWF5IGhhdmUg YSB0eXBlIHRhYmxlLAovLyBhbmQgaGF2ZSBhIHNjb3BlCnNpZyBFbGVtRGVjbCB7CiAgbmFtZSA6 IHFuLAogIGRlY2xhcmVkX3R5cGUgOiBUeXBlRGVmLAogIHR0YWJsZSA6IGxvbmUgdHQsCiAgc2Nv cGUgOiAoa3dHbG9iYWwgKyBUeXBlRGVmKQp9ewogIC8vIGFueSBlbGVtZW50IGRlY2xhcmF0aW9u IHNjb3BlZCB0byBhIHR5cGUgbXVzdCBiZSAKICAvLyBhbW9uZyB0aGF0IHR5cGUncyBjaGlsZHJl bgogIGFsbCB0IDogVHlwZURlZiB8IHNjb3BlID0gdCA9PiB0aGlzIGluIHQuZWxlbUNoaWxkcmVu Cn0KCi8vIFdpbGRjYXJkcyBtYXRjaCBRTmFtZXMgYW5kIGhhdmUgYSBraW5kOiAgdGhleSBhcmUg c3RyaWN0LCBvcgovLyBsYXgsIG9yIHNraXAgd2lsZGNhcmRzLiAgV2UgZGVmaW5lIHRoZW0gYXMg c2VwYXJhdGUgc3VidHlwZXMKLy8gcHJpbWFyaWx5IHNvIHRoYXQgaXQgaXMgbW9yZSBjb252ZW5p ZW50IHRvIHN0eWxlIHRoZW0gZGlmZmVyZW50bHkKLy8gaW4gdmlzdWFsaXphdGlvbnMgb2YgaW5z dGFuY2VzLgphYnN0cmFjdCBzaWcgV2lsZENhcmQgewogIG1hdGNoZXMgOiBzZXQgcW4sCiAga2lu ZCA6IChrd1N0cmljdCArIGt3TGF4ICsga3dTa2lwKQp9CnNpZyBTdHJpY3RXQyBleHRlbmRzIFdp bGRDYXJkIHt9ewogIGtpbmQgPSBrd1N0cmljdAp9CnNpZyBMYXhXQyBleHRlbmRzIFdpbGRDYXJk IHt9ewogIGtpbmQgPSBrd0xheAp9CnNpZyBTa2lwV0MgZXh0ZW5kcyBXaWxkQ2FyZCB7fXsKICBr aW5kID0ga3dTa2lwCn0KCi8vIFRoaXJkLCB0eXBlIGRlZmluaXRpb25zLiAgCgovLyBUeXBlIGRl ZmluaXRpb25zIGhhdmUgZWxlbWVudCBjaGlsZHJlbiBhbmQgd2lsZGNhcmQgY2hpbGRyZW4uCi8v IEFuZCBjcnVjaWFsbHkgZm9yIG91ciBwdXJwb3NlcywgdGhleSBhbHNvIGRlZmluZSBhIG1hcHBp bmcKLy8gZnJvbSBRTmFtZXMgdG8gdGhlaXIgY29udGV4dC1kZXRlcm1pbmVkIHR5cGUgdGFibGVz IChjdHQpLiAgCi8vIFdlIGRvbid0IGRpc3Rpbmd1aXNoIHRvcC1sZXZlbCBmcm9tIGxvY2FsIHR5 cGVzOyB0aGUKLy8gZGlzdGluY3Rpb24gZG9lcyBub3QgYXBwZWFyIGltcG9ydGFudCBmb3IgdGhp cyBpc3N1ZS4KCnNpZyBUeXBlRGVmIHsKICBlbGVtQ2hpbGRyZW4gOiBzZXQgRWxlbURlY2wsCiAg d2NDaGlsZHJlbiA6IHNldCBXaWxkQ2FyZCwKICBjdHQgOiBxbiAtPiB0dAp9ewoKICAvLyBIZXJl IHdlIGNvbnN0cmFpbiB0aGUgVHlwZURlZiBzaWduYXR1cmUgc28gdGhhdCBlYWNoIGN0dAogIC8v IGluY2x1ZGVzIGV2ZXJ5dGhpbmcgdGhlIHNwZWMgc2F5cyB0byBpbmNsdWRlLCBhbmQgbm90aGlu ZyAKICAvLyBlbHNlCgogIC8qIFdoYXQgdGhlIHNwZWMgc2F5cywgaW4gMy40LjQuMSwgaXM6Cgog ICAgIFNpbWlsYXJseTogW0RlZmluaXRpb246XSBFdmVyeSBDb21wbGV4IFR5cGUgRGVmaW5pdGlv bgogICAgIGRldGVybWluZXMgYSBwYXJ0aWFsIGZ1bmN0aW9uYWwgbWFwcGluZyBmcm9tIGVsZW1l bnQKICAgICBpbmZvcm1hdGlvbiBpdGVtcyAoYW5kIHRoZWlyIGV4cGFuZGVkIG5hbWVzKSB0byBU eXBlCiAgICAgVGFibGVzLiBUaGUgVHlwZSBUYWJsZSBpZGVudGlmaWVkIGJ5IHRoaXMgbWFwcGlu ZyBpcyB0aGUKICAgICBjb250ZXh0LWRldGVybWluZWQgdHlwZSB0YWJsZSBmb3IgZWxlbWVudHMg d2hpY2ggbWF0Y2ggYQogICAgIFBhcnRpY2xlIGNvbnRhaW5lZCBieSB0aGUgY29udGVudCBtb2Rl bCBvZiB0aGUgQ29tcGxleCBUeXBlCiAgICAgRGVmaW5pdGlvbi4gRm9yIGEgZ2l2ZW4gQ29tcGxl eCBUeXBlIERlZmluaXRpb24gVCBhbmQgYQogICAgIGdpdmVuIGVsZW1lbnQgaW5mb3JtYXRpb24g aXRlbSBFLCB0aGUgY29udGV4dC1kZXRlcm1pbmVkCiAgICAgdHlwZSB0YWJsZSBvZiBFIGluIFQg aXMgYXMgZm9sbG93czoKCiAgICAgMSBMZXQgRCBiZSBhbiBFbGVtZW50IERlY2xhcmF0aW9uIG1h dGNoZWQgYnkgRSwgZ2l2ZW4gYnkKICAgICAgIHRoZSBmaXJzdCBjYXNlIGFtb25nIHRoZSBmb2xs b3dpbmcgd2hpY2ggYXBwbGllczoKCiAgICAgICAxLjEgSWYgRSBoYXMgdGhlIHNhbWUgZXhwYW5k ZWQgbmFtZSBhcyBzb21lIGVsZW1lbnQKICAgICAgICAgICBkZWNsYXJhdGlvbihzKSBjb250YWlu ZWQgYnkgVCdzIGNvbnRlbnQgbW9kZWwsIHdoZXRoZXIKICAgICAgICAgICBkaXJlY3RseSwgaW5k aXJlY3RseSwgb3IgaW1wbGljaXRseSwgdGhlbiBsZXQgRCBiZSBhbnkKICAgICAgICAgICBvbmUg b2YgdGhvc2UgRWxlbWVudCBEZWNsYXJhdGlvbnMuCgogICAgICAgMS4yIElmIEUgbWF0Y2hlcyBz b21lIHdpbGRjYXJkIHBhcnRpY2xlIGNvbnRhaW5lZCBieQogICAgICAgICAgIFQncyBjb250ZW50 IG1vZGVsLCB3aGV0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIGFuZAogICAgICAgICAgIEUg bWF0Y2hlcyBzb21lIHRvcC1sZXZlbCBFbGVtZW50IERlY2xhcmF0aW9uLCB0aGVuIGxldAogICAg ICAgICAgIEQgYmUgdGhhdCB0b3AtbGV2ZWwgRWxlbWVudCBEZWNsYXJhdGlvbi4iICBbYW5kIGNs YXVzZQogICAgICAgICAgIDIuMSBhZ2Fpbl0KCiAgICAgMiBJZiBFIG1hdGNoZXMgc29tZSBFbGVt ZW50IERlY2xhcmF0aW9uIGFzIGRlc2NyaWJlZCBhYm92ZQogICAgICAgaW4gY2xhdXNlIDEsIHRo ZW4gdGhlIGNvbnRleHQtZGV0ZXJtaW5lZCB0eXBlIHRhYmxlIG9mIEUKICAgICAgIGluIFQgaXMg Z2l2ZW4gYnkgdGhlIGFwcHJvcHJpYXRlIGNhc2UgYW1vbmcgdGhlIGZvbGxvd2luZzoKCiAgICAg ICAyLjEgSWYgRCBoYXMgYSBUeXBlIFRhYmxlLCB0aGVuIHRoZSBjb250ZXh0LWRldGVybWluZWQK ICAgICAgICAgICB0eXBlIHRhYmxlIG9mIEUgaW4gVCBpcyB0aGUgVHlwZSBUYWJsZSBvZiBECgog ICAgICAgMi4yIElmIEQgaGFzIG5vIFR5cGUgVGFibGUsIHRoZW4gdGhlCiAgICAgICAgICAgY29u dGV4dC1kZXRlcm1pbmVkIHR5cGUgdGFibGUgb2YgRSBpbiBUIGlzIHRoZSBUeXBlCiAgICAgICAg ICAgVGFibGUgd2hvc2Uge2FsdGVybmF0aXZlc30gaXMgdGhlIGVtcHR5IHNlcXVlbmNlIGFuZAog ICAgICAgICAgIHdob3NlIHtkZWZhdWx0IHR5cGUgZGVmaW5pdGlvbn0gaXMgYSBUeXBlIEFsdGVy bmF0aXZlCiAgICAgICAgICAgd2hvc2Uge3Rlc3R9IGlzIGFic2VudCBhbmQgd2hvc2Uge3R5cGUg ZGVmaW5pdGlvbn0gaXMKICAgICAgICAgICB0aGUgZGVjbGFyZWQge3R5cGUgZGVmaW5pdGlvbn0g b2YgRC4KCiovCiAgYWxsIFEgOiBxbiB8IGFsbCBUIDogdHQgfAogICAgKFEgLT4gVCBpbiBjdHQp IGlmZgoKICAgIC8vIENsYXVzZSAxLjEgKyAyLjEKICAgIChzb21lIEVEIDogZWxlbUNoaWxkcmVu IHwgCiAgICAgICAgUSA9IEVELm5hbWUgYW5kIFQgPSBFRC50dGFibGUgKSAKCiAgICAvLyBDbGF1 c2VzIDEuMSArIDIuMgogICAgb3IgKHNvbWUgRUQgOiBlbGVtQ2hpbGRyZW4gfCAKICAgICAgICBR ID0gRUQubmFtZSAKICAgICAgICBhbmQgbm8gRUQudHRhYmxlIAogICAgICAgIGFuZCBUIGluIGNv bnN0cnVjdGVkX3R0CiAgICAgICAgYW5kIFQuZGVmYXVsdF90eXBlID0gRUQuZGVjbGFyZWRfdHlw ZQogICAgKQoKICAgIC8vIENsYXVzZXMgMS4yIGFuZCAyLjEKICAgIG9yICggKG5vIEVEIDogZWxl bUNoaWxkcmVuIHwgUSA9IEVELm5hbWUpCiAgICAgICBhbmQgCiAgICAgICAoc29tZSBXIDogd2ND aGlsZHJlbiB8IHNvbWUgRyA6IEVsZW1EZWNsIHwgCiAgICAgICAgIFEgaW4gVy5tYXRjaGVzCiAg ICAgICAgIGFuZCBHLm5hbWUgPSBRCiAgICAgICAgIGFuZCBHLnNjb3BlID0ga3dHbG9iYWwKICAg ICAgICAgYW5kIEcudHRhYmxlID0gVAogICAgICApCiAgICApIAoKICAgIC8vIENsYXVzZXMgMS4y ICsgMi4yIAogICAgb3IgKChubyBFRCA6IGVsZW1DaGlsZHJlbiB8IFEgPSBFRC5uYW1lKQogICAg ICAgYW5kIAogICAgICAgKHNvbWUgVyA6IHdjQ2hpbGRyZW4gfCBzb21lIEcgOiBFbGVtRGVjbCB8 CiAgICAgICAgIFEgaW4gVy5tYXRjaGVzCiAgICAgICAgIGFuZCBHLm5hbWUgPSBRCiAgICAgICAg IGFuZCBHLnNjb3BlID0ga3dHbG9iYWwKICAgICAgICAgYW5kIG5vIEcudHRhYmxlCiAgICAgICAg IGFuZCBUIGluIGNvbnN0cnVjdGVkX3R0IAogICAgICAgICBhbmQgVC5kZWZhdWx0X3R5cGUgPSBH LmRlY2xhcmVkX3R5cGUKICAgICAgKQogICAgKQoKfQoKLy8gTm8gdHdvIHRvcC1sZXZlbCBlbGVt ZW50IGRlY2xhcmF0aW9ucyBoYXZlIHRoZSBzYW1lCi8vIGV4cGFuZGVkIG5hbWUuICAKZmFjdCB0 b3BfbGV2ZWxfRURfdW5pcXVlIHsKICBhbGwgRTEsIEUyIDogRWxlbURlY2wgfAogICAgRTEuc2Nv cGUgPSBrd0dsb2JhbCAKICAgIGFuZCBFMi5zY29wZSA9IGt3R2xvYmFsCiAgICBhbmQgRTEubmFt ZSA9IEUyLm5hbWUKICAgID0+IEUxID0gRTIKfQoKLy8gWFNEIDEuMSBTdHJ1Y3R1cmVzLCBzZWMu IDMuOC42LjMgaW1wb3NlcyB0aGUgY29uc3RyYWludCAKLy8gRWxlbWVudCBEZWNsYXJhdGlvbnMg Q29uc2lzdGVudC4gIFdlIGRlZmluZSBpdCBhcyBhIHByZWRpY2F0ZQovLyByYXRoZXIgdGhhbiBh IGZhY3QsIHNvIHRoYXQgd2UgY2FuIGV4cGxvcmUgdGhlIGVmZmVjdCBvZiBoYXZpbmcKLy8gaXQg YW5kIG5vdCBoYXZpbmcgaXQuCgovKiBXaGF0IHRoZSBzcGVjIHNheXMgaXM6CgogICAgU2NoZW1h IENvbXBvbmVudCBDb25zdHJhaW50OiBFbGVtZW50IERlY2xhcmF0aW9ucyBDb25zaXN0ZW50Cgog ICAgSWYgdGhlIHtwYXJ0aWNsZXN9IHByb3BlcnR5IGNvbnRhaW5zLCBlaXRoZXIgZGlyZWN0bHks CiAgICBpbmRpcmVjdGx5ICh0aGF0IGlzLCB3aXRoaW4gdGhlIHtwYXJ0aWNsZXN9IHByb3BlcnR5 IG9mIGEKICAgIGNvbnRhaW5lZCBtb2RlbCBncm91cCwgcmVjdXJzaXZlbHkpLCBvciBpbXBsaWNp dGx5LCB0d28gb3IKICAgIG1vcmUgZWxlbWVudCBkZWNsYXJhdGlvbnMgd2l0aCB0aGUgc2FtZSBl eHBhbmRlZCBuYW1lLCB0aGVuCiAgICBhbGwgdGhlaXIgdHlwZSBkZWZpbml0aW9ucyBtdXN0IGJl IHRoZSBzYW1lIHRvcC1sZXZlbAogICAgZGVmaW5pdGlvbiwgdGhhdCBpcywgYWxsIG9mIHRoZSBm b2xsb3dpbmcgbXVzdCBiZSB0cnVlOgoKICAgICAgMSBBbGwgdGhlaXIgZGVjbGFyZWQge3R5cGUg ZGVmaW5pdGlvbn1zIGhhdmUgYSBub24tYWJzZW50CiAgICAgICAge25hbWV9LgoKICAgICAgMiBB bGwgdGhlaXIgZGVjbGFyZWQge3R5cGUgZGVmaW5pdGlvbn1zIGhhdmUgdGhlIHNhbWUKICAgICAg ICB7bmFtZX0uCgogICAgICAzIEFsbCB0aGVpciBkZWNsYXJlZCB7dHlwZSBkZWZpbml0aW9ufXMg aGF2ZSB0aGUgc2FtZQogICAgICAgIHt0YXJnZXQgbmFtZXNwYWNlfS4KCiAgICAgIDQgQWxsIHRo ZWlyIHt0eXBlIHRhYmxlfXMgYXJlIGVpdGhlciBhbGwgYWJzZW50IG9yIGVsc2UKICAgICAgICBh bGwgYXJlIHByZXNlbnQgYW5kIGhhdmUgdGhlIHNhbWUgc2VxdWVuY2Ugb2YKICAgICAgICB7YWx0 ZXJuYXRpdmVzfSBhbmQgdGhlIHNhbWUge2RlZmF1bHQgdHlwZSBkZWZpbml0aW9ufS4KCiAgICBJ ZiBhbGwgb2YgdGhlIGZvbGxvd2luZyBhcmUgdHJ1ZToKCiAgICAgIDEgVGhlIHtwYXJ0aWNsZXN9 IHByb3BlcnR5IGNvbnRhaW5zIChlaXRoZXIgZGlyZWN0bHksCiAgICAgICAgaW5kaXJlY3RseSwg b3IgaW1wbGljaXRseSkgb25lIG9yIG1vcmUgZWxlbWVudAogICAgICAgIGRlY2xhcmF0aW9ucyB3 aXRoIHRoZSBzYW1lIGV4cGFuZGVkIG5hbWUgUTsgY2FsbCB0aGVzZQogICAgICAgIGVsZW1lbnQg ZGVjbGFyYXRpb25zIEVEUy4KCiAgICAgIDIgQXQgbGVhc3Qgb25lIG9mIHRoZSBmb2xsb3dpbmcg aXMgdHJ1ZQoKICAgICAgICAyLjEgVGhlIHtwYXJ0aWNsZXN9IHByb3BlcnR5IGNvbnRhaW5zIG9u ZSBvciBtb3JlCiAgICAgICAgICAgIHN0cmljdCBvciBsYXggd2lsZGNhcmQgcGFydGljbGVzIHdo aWNoIG1hdGNoIFEuCgogICAgICAgIDIuMiBUaGUgTW9kZWwgR3JvdXAgaXMgdGhlIHt0ZXJtfSBv ZiB0aGUgY29udGVudAogICAgICAgICAgICBtb2RlbCBvZiBzb21lIENvbXBsZXggVHlwZSBEZWZp bml0aW9uIENURCBhbmQKICAgICAgICAgICAgQ1RELntjb250ZW50IHR5cGV9IGhhcyBhbiB7b3Bl biBjb250ZW50fSB3aXRoIGEKICAgICAgICAgICAgc3RyaWN0IG9yIGxheCBXaWxkY2FyZCB3aGlj aCBtYXRjaGVzIFEuCgogICAgICAzIFRoZXJlIGV4aXN0cyBhIHRvcC1sZXZlbCBlbGVtZW50IGRl Y2xhcmF0aW9uIEcgd2l0aCB0aGUKICAgICAgICBleHBhbmRlZCBuYW1lIFEuCgogICAgdGhlbiB0 aGUge3R5cGUgdGFibGV9cyBvZiBFRFMgYW5kIHRoZSB7dHlwZSB0YWJsZX0gb2YgRyBtdXN0CiAg ICBlaXRoZXIgYWxsIGJlIGFic2VudCBvciBlbHNlIGFsbCBiZSBwcmVzZW50IGFuZCBoYXZlIHRo ZSBzYW1lCiAgICBzZXF1ZW5jZSBvZiB7YWx0ZXJuYXRpdmVzfSBhbmQgdGhlIHNhbWUge2RlZmF1 bHQgdHlwZQogICAgZGVmaW5pdGlvbn0uCiAgKi8KCi8vIHRyYW5zbGF0ZWQgbm93IGludG8gQWxs b3ksIHRoaXMgaXM6CnByZWQgRURDIHsKCiAgYWxsIFQgOiBUeXBlRGVmIHwgYWxsIEUxLCBFMiA6 IEVsZW1EZWNsIHwKICAgIChFMSBpbiBULmVsZW1DaGlsZHJlbiBhbmQgRTIgaW4gVC5lbGVtQ2hp bGRyZW4pCiAgICA9PiAKICAgIChFMS5kZWNsYXJlZF90eXBlID0gRTIuZGVjbGFyZWRfdHlwZQog ICAgYW5kIEUxLnR0YWJsZSA9IEUyLnR0YWJsZSkKCiAgYWxsIFQgOiBUeXBlRGVmIHwgYWxsIEVE UywgRUcgOiBFbGVtRGVjbCB8IGFsbCBXIDogV2lsZENhcmQgfAogICAgKCBFRFMgaW4gVC5lbGVt Q2hpbGRyZW4gCiAgICAgIGFuZCBXIGluIFQud2NDaGlsZHJlbgogICAgICBhbmQgVy5raW5kIGlu IChrd1N0cmljdCArIGt3TGF4KQogICAgICBhbmQgRURTLm5hbWUgaW4gVy5tYXRjaGVzCiAgICAg IGFuZCBFRFMubmFtZSA9IEVHLm5hbWUKICAgICkgPT4gKAogICAgICBFRFMudHRhYmxlID0gRUcu dHRhYmxlCiAgICApCn0KCnJ1biB7fSBmb3IgMwoKLy8gVGVzdCB0aGUgY2xhaW0gdGhhdCB0aGUg Y29udGV4dC1kZXRlcm1pbmVkIHR5cGUgdGFibGUKLy8gZm9yIGEgZ2l2ZW4gUU5hbWUsIGluIGEg Z2l2ZW4gdHlwZSwgaXMgdW5pcXVlLgphc3NlcnQgY3R0X3VuaXF1ZSB7CiAgYWxsIFEgOiBxbiB8 IGFsbCBUIDogVHlwZURlZiB8IGxvbmUgUS4oVC5jdHQpCn0KY2hlY2sgY3R0X3VuaXF1ZSBmb3Ig MwovLyBUaGVyZSBhcmUgY291bnRlci1leGFtcGxlcywgd2hpY2ggc2hvd3MgdGhhdCB0aGUgZGVm aW5pdGlvbgovLyBvZiBjdHQgaXMgbm90IGJ5IGl0c2VsZiBlbm91Z2ggdG8gbWFrZSB0aGUgY29u dGV4dC1kZXRlcm1pbmVkCi8vIHR5cGUgdGFibGUgdW5pcXVlLgoKLy8gTm93IHRlc3QgdGhlIHBy b3Bvc2l0aW9uIGluIHRoZSBOb3RlOgovKiAKCiAgICBOb3RlOiBUaGUgY29uc3RyYWludCBFbGVt ZW50IERlY2xhcmF0aW9ucyBDb25zaXN0ZW50CiAgICAow4LCpzMuOC42LjMpIGVuc3VyZXMgdGhh dCBldmVuIGlmIEUgbWF0Y2hlcyBtb3JlIHRoYW4gb25lIHN1Y2gKICAgIGRlY2xhcmF0aW9uIEQs IHRoZXJlIHdpbGwgYmUganVzdCBvbmUgY29udGV4dC1kZXRlcm1pbmVkIHR5cGUKICAgIHRhYmxl LiIKCiovCmFzc2VydCBFRENfZW50YWlsc19jdHRfdW5pcXVlIHsKICBFREMgPT4gKGFsbCBRIDog cW4gfCBhbGwgVCA6IFR5cGVEZWYgfCBsb25lIFEuKFQuY3R0KSkKfQpjaGVjayBFRENfZW50YWls c19jdHRfdW5pcXVlIGZvciA3Cg==