<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>3756</bug_id>
          
          <creation_ts>2006-09-20 22:50:31 +0000</creation_ts>
          <short_desc>Pre-canonicalize the testsuite</short_desc>
          <delta_ts>2006-09-25 22:48:15 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XML Query Test Suite</product>
          <component>XML Query Test Suite</component>
          <version>unspecified</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>WONTFIX</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>enhancement</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Per Bothner">per</reporter>
          <assigned_to name="Andrew Eisenberg">andrew.eisenberg</assigned_to>
          
          
          <qa_contact name="Mailing list for public feedback on specs from XSL and XML Query WGs">public-qt-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>11896</commentid>
    <comment_count>0</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-20 22:50:31 +0000</bug_when>
    <thetext>The following files contains XML or Fragment expected output with xmlns declarations that are *not* in canonical order:

(See http://www.w3.org/TR/xml-c14n#DocumentOrder.)

fn-union-node-args-015.txt
fn-union-node-args-016.txt
fn-union-node-args-017.txt
fn-intersect-node-args-015.txt
fn-intersect-node-args-016.txt
fn-except-node-args-017.txt
Constr-cont-nsmode-1.xml
Constr-inscope-1.xml (&apos;XXX&apos; is lexicographically before &apos;foo&apos;)
Constr-inscope-2.xml
Constr-inscope-3.xml
Constr-inscope-4.xml
ns-queries-results-q2.txt
ns-queries-results-q3.txt
ns-queries-results-q5.txt
ns-queries-results-q6.txt
ns-queries-results-q7.txt
ns-queries-results-q8.txt

There may be similar issues with order of attribute nodes; I haven&apos;t inspect that yet.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11934</commentid>
    <comment_count>1</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-09-21 07:46:14 +0000</bug_when>
    <thetext>The spec say that &quot;The test harness must canonicalize both the actual result and the expected result according to the Canonical XML recommendation&quot;

There&apos;s no statement anywhere, AFAIK, that the published results are already canonicalized.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11936</commentid>
    <comment_count>2</comment_count>
    <who name="Frans Englich">frans.englich</who>
    <bug_when>2006-09-21 09:13:36 +0000</bug_when>
    <thetext>I believe Michael&apos;s comment is right here. None of the XML results are purposefully canonical(although that can be the case for some tests), but require that the implementor do the canonicalization, or use a semantically equivalent method. For example, I load the XML into DOM trees and compare them. Slow, but it works.

Therefore, I&apos;m closing this report as invalid. Per, if this resolution is ok, feel free to change status to CLOSED, otherwise re-open the bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11943</commentid>
    <comment_count>3</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-21 15:49:45 +0000</bug_when>
    <thetext>Ok, I changed the severity to &quot;enhancement&quot;.  The reason is I sometimes run the testsuite many times an hour.  Having to canonicalize the expected output adds an extra processing step which slows down running the testsuite.  (Since I haven&apos;t yet implemented this extra step I don&apos;t know how much.)  It would be much more efficient to pre-canonicalize the testsuite.  As there doesn&apos;t seemt o be that many testsuites that aren&apos;t already canonicalized it should be fairly easy to do.  (I volunteer to send patches if you&apos;ll accept this change in principle.)  It makes more sense to change a few test cases rather than run an extra canonicalization step on *each* non-error testcase.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11944</commentid>
    <comment_count>4</comment_count>
    <who name="Frans Englich">frans.englich</who>
    <bug_when>2006-09-21 16:11:13 +0000</bug_when>
    <thetext>I think it is a reasonable suggestion, and I wouldn&apos;t mind to see it done either, I think. The question is whether it&apos;s feasible:

How would fragments be handled? Those are messy since c14n tools will choke on non-XML input(I guess). One could wrap them with an element and leave it there but that would require existing drivers to be changed, and also require them to wrap their output in a particular way. Another approach is to try to remove the document element afterwards, but this is all getting messy. As I currently see it, XML fragments are a show stopper for this enhancement.

It should probably be implemented as a tool that the task force run on the suite(just like all our other scripts), to ensure maintainability. The smartest thing would probably be to extract the K-* tests into the CVS rep., as suggested by several(including me), otherwise they would pose a problem.

But again, in principle the idea is good. Especially since it feels like this test infrastructure will be used for future XQuery extensions. However, there&apos;s a general conservatism towards changes in the XQTS(understandably), so I wouldn&apos;t expect anything to change any time soon.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11945</commentid>
    <comment_count>5</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-21 16:56:06 +0000</bug_when>
    <thetext>(In reply to comment #4)
&gt; How would fragments be handled? Those are messy since c14n tools will choke on
&gt; non-XML input(I guess). One could wrap them with an element and leave it there
&gt; but that would require existing drivers to be changed, and also require them to
&gt; wrap their output in a particular way. Another approach is to try to remove the
&gt; document element afterwards, but this is all getting messy. As I currently see
&gt; it, XML fragments are a show stopper for this enhancement.

First, we may not need a tool, if most of the tests are already canonicalized, which they seem to be.  The number of mis-ordered namespace declarations that I found is quite modest.  Attribute order may be another (unknown) problem.  And there may be soem whitespace issues.  If the discrepancies are modest, we could just fix them manually.  I can certainly submit patches for the namespace-declaration &quot;errors&quot;.

Secondly, I don&apos;t see that handling Fragments shoudl be difficult.  Surround the Fragment by some magical header like &lt;xqts-magic-frag-wrapper&gt; ... &lt;/xqts-magic-frag-wrapper&gt; before running the canonicalizer.  Removing the header afterwards should just be a trivial sed/perl script.  Am I missing something?

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11946</commentid>
    <comment_count>6</comment_count>
      <attachid>439</attachid>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-21 19:04:20 +0000</bug_when>
    <thetext>Created attachment 439
sort order of namespace declarations in some test output

This &quot;fixes&quot; 6 of the test cases on my list so the namespaces declarations are &quot;canonically&quot; sorted.  This improves the number of passing tests for Qexo.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11947</commentid>
    <comment_count>7</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-21 19:13:47 +0000</bug_when>
    <thetext>If the previous patch is accepted (which I woukd much appreciate) I&apos;ll submit a similar patch for the remaining namespace-declaration-order cases.

I did find one rather larger discrepency from canonical output: Most of the results &quot;short-cut&quot; end-tags, which is not allowed by canonical XML.  I.e.
&lt;foo attributes.../&gt; rather than &lt;foo attributes...&gt;&lt;/foo&gt;.  When I changed my output routine to emit the latter rather than the former, then the number of passes dropped by 174 in my testing.  &quot;Fixing&quot; these manually will be somewhat more tedious.

Of course the goal isn&apos;t necessarily &quot;canonical XML&quot; as it is a well-specified and predictable output format.  So &quot;canonical XML but with end-tag abbreviation&quot; is a reasonable option for expected output files, at least as an interim step for XQTS 1.0.x.

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11948</commentid>
    <comment_count>8</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-09-21 22:05:47 +0000</bug_when>
    <thetext>What I do is to first compare my test results with the published results as a simple string compare. Only if that fails do I try to canonicalize. If, as you suggest, most of the results are in canonical form already, this procedure efectively eliminates any performance impact of canonicalization.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11949</commentid>
    <comment_count>9</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-22 05:54:47 +0000</bug_when>
    <thetext>(In reply to comment #8)
&gt; What I do is to first compare my test results with the published results as a
&gt; simple string compare. Only if that fails do I try to canonicalize. If, as you
&gt; suggest, most of the results are in canonical form already, this procedure
&gt; efectively eliminates any performance impact of canonicalization.

That is certainly a practical work-around. But we&apos;re talking about a testsuite, and running the testsuite should be as simple and regular as possible, to avoid artifacts and errors in the testsuite and testing framework.  The more complicated the comparison is, and the more different ways we try finding a match between expected and actual output, then the greater the risk of errors in the testing framework or otherwise missing actual bugs in the implementation.

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11950</commentid>
    <comment_count>10</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-09-22 08:37:40 +0000</bug_when>
    <thetext>&gt;running the testsuite should be as simple and regular as possible

That suggests that it&apos;s better for the test suite to use the output format that most processors are likely to generate from their everyday serializers, for example &lt;a/&gt;, rather than the canonicalized form which is &lt;a&gt;&lt;/a&gt;.

But I&apos;m probably influenced by the fact that I chose not to use canonicalization as my comparison method: instead (assuming string comparison fails) I use a customized variant of the deep-equal() function applied to the two node trees.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>11961</commentid>
    <comment_count>11</comment_count>
    <who name="Frans Englich">frans.englich</who>
    <bug_when>2006-09-22 14:36:33 +0000</bug_when>
    <thetext>If any kind of output normalization is deployed it needs to be done in a verifiable and maintainable way. A patch or two can fix some issues that are found by a particular harness driver at this point, but it doesn&apos;t help when bugs are fixed and the test suite is potentially further developed in the future. That&apos;s why I mention a tool here, such that the task force can guarantee any promises it gives.

So, I doubt patches would be accepted. However, I do think the more general ideas behind this surely has it merits and that it should be considered for further development.

My best advice is what Michael said; to do string comparisons and in the cases they fail, fallback to c14n comparison(or functional equivalent).

This is only my personal response. The task force will discuss and take action on this report.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12013</commentid>
    <comment_count>12</comment_count>
    <who name="Andrew Eisenberg">andrew.eisenberg</who>
    <bug_when>2006-09-25 20:12:12 +0000</bug_when>
    <thetext>The Testing TF discussed this at our meeting on Sept. 21 and decline to make this change. In part this is because our decision to have implementors canonicalize the expected result is one that was made a very long time ago and has been found acceptable by many implementors. In part this is also because we are about to &quot;declare victory&quot; when we publish XQTS 1.0.1 (containing bug fixes for reports that we&apos;ve received over the last several weeks).

I suggest that if you want to reduce the cost running the test suite repeatedly, that you first replace our expected results with their canonic representations on your local copy. We may produce some versions of XQTS beyond 1.0.1, but these will likely be few and far between.

By the way, we do acknowledge and appreciate the offer of your labor for the change that you suggest.

Please close this bug report if you agree with this resolution.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12016</commentid>
    <comment_count>13</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-25 21:47:57 +0000</bug_when>
    <thetext>(In reply to comment #12)
&gt; In part this is because our decision to have implementors
&gt; canonicalize the expected result is one that was made a very long time ago and
&gt; has been found acceptable by many implementors.

The problem is that this can mroe easily hide errors, thus making the testsuite stricly less powerful.  To verify that matches(ACTUAL,EXPECTED) by doing match(canonicalize(ACTAL),canonicalize(EXPECTED)) is doing a stricly less powerful test.  A bug in canonicalize can lead to a false positive.  Alternatively, if canonicalize &quot;throws away too much information&quot; you can also get false positives.  E.g. if someone implements canonicalize by taking the string value of the argument then a test case is more likely to pass even in an implementation fails to emit correct namespace declarations.

&gt; In part this is also because we
&gt; are about to &quot;declare victory&quot; when we publish XQTS 1.0.1 (containing bug fixes
&gt; for reports that we&apos;ve received over the last several weeks).

Yes, I understand the timing issue, and I apologize for not brining this issue up earlier.
&gt; 
&gt; I suggest that if you want to reduce the cost running the test suite
&gt; repeatedly, that you first replace our expected results with their canonic
&gt; representations on your local copy.

I not so concerned about the cost (as Mike Kay said one only needs to do canonicalization for the relatively few tests that aren&apos;t canonicalized), but it does reduce the &quot;power&quot; of the testsuite, and its usefulness in avoiding regressions.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12017</commentid>
    <comment_count>14</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-09-25 22:28:51 +0000</bug_when>
    <thetext>&gt;if someone implements canonicalize by taking the string value of the argument

but that wouldn&apos;t implement canonicalize.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12018</commentid>
    <comment_count>15</comment_count>
    <who name="Per Bothner">per</who>
    <bug_when>2006-09-25 22:48:15 +0000</bug_when>
    <thetext>(In reply to comment #14)
&gt; but that wouldn&apos;t implement canonicalize.

My point is: how could you tell?  Unless you had a separate test-suite for canonicalization.  Using the string value is an extreme and unlikely case, but some more subtle bug in the canonicalization mechanism could easily mask a real error.

You mentioned you use a &quot;customized variant&quot; of deep-equal.  A lazy implementor might use deep-equal, without remembering that it doesn&apos;t check namespace declarations or element/attribute prefixes or nested comments or nested processing instructions.

Plus of course one might want to check that serialization works as expected.  using a variant of deep-equal doesn&apos;t do that.

</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>439</attachid>
            <date>2006-09-21 19:04:20 +0000</date>
            <delta_ts>2006-09-21 19:04:20 +0000</delta_ts>
            <desc>sort order of namespace declarations in some test output</desc>
            <filename>ns-queries-results.patch</filename>
            <type>text/plain</type>
            <size>9616</size>
            <attacher name="Per Bothner">per</attacher>
            
              <data encoding="base64">SW5kZXg6IC4vRXhwZWN0ZWRUZXN0UmVzdWx0cy9Vc2VDYXNlL1VzZUNhc2VOUy9ucy1xdWVyaWVz
LXJlc3VsdHMtcTIudHh0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9zb3VyY2VzL3B1YmxpYy8yMDA2
L3hxdWVyeS10ZXN0LXN1aXRlL1Rlc3RTdWl0ZVN0YWdpbmdBcmVhL0V4cGVjdGVkVGVzdFJlc3Vs
dHMvVXNlQ2FzZS9Vc2VDYXNlTlMvbnMtcXVlcmllcy1yZXN1bHRzLXEyLnR4dCx2CnJldHJpZXZp
bmcgcmV2aXNpb24gMS4zCmRpZmYgLXIxLjMgbnMtcXVlcmllcy1yZXN1bHRzLXEyLnR4dAoxYzEK
PCA8UTI+PHRpdGxlIHhtbG5zPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL211c2ljL3JlY29yZHMi
IHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxp
bms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93
d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDov
L3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRw
Oi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iPkluIGEgU2lsZW50IFdheTwv
dGl0bGU+PHRpdGxlIHhtbG5zPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL211c2ljL3JlY29yZHMi
IHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxp
bms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93
d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDov
L3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRw
Oi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iPlRoaW5rIG9mIE9uZSAuLi48
L3RpdGxlPjwvUTI+ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQotLS0KPiA8UTI+PHRpdGxl
IHhtbG5zPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL211c2ljL3JlY29yZHMiIHhtbG5zOmFueXpv
bmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFj
aGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczpt
YT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9BdWN0aW9uV2F0Y2giIHhtbG5zOnhsaW5rPSJodHRw
Oi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iPkluIGEgU2lsZW50IFdheTwvdGl0bGU+PHRpdGxl
IHhtbG5zPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL211c2ljL3JlY29yZHMiIHhtbG5zOmFueXpv
bmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFj
aGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczpt
YT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9BdWN0aW9uV2F0Y2giIHhtbG5zOnhsaW5rPSJodHRw
Oi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iPlRoaW5rIG9mIE9uZSAuLi48L3RpdGxlPjwvUTI+
ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpJbmRleDogLi9FeHBlY3RlZFRlc3RSZXN1bHRz
L1VzZUNhc2UvVXNlQ2FzZU5TL25zLXF1ZXJpZXMtcmVzdWx0cy1xMy50eHQKPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpS
Q1MgZmlsZTogL3NvdXJjZXMvcHVibGljLzIwMDYveHF1ZXJ5LXRlc3Qtc3VpdGUvVGVzdFN1aXRl
U3RhZ2luZ0FyZWEvRXhwZWN0ZWRUZXN0UmVzdWx0cy9Vc2VDYXNlL1VzZUNhc2VOUy9ucy1xdWVy
aWVzLXJlc3VsdHMtcTMudHh0LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjMKZGlmZiAtcjEuMyBu
cy1xdWVyaWVzLXJlc3VsdHMtcTMudHh0CjFjMQo8IDxRMz48bWE6T3BlbiB4bWxuczpkdD0iaHR0
cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkv
eGxpbmsiIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMj
YW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVy
cyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25l
ZXJzI3lhYmFkb28iIGR0OnR5cGU9InRpbWVJbnN0YW50Ij4yMDAwLTAzLTIxOjA3OjQxOjM0LTA1
OjAwPC9tYTpPcGVuPjxtYTpDbG9zZSB4bWxuczpkdD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9Y
TUxTY2hlbWEiIHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIg
eG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOmFueXpvbmU9
Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJh
eT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczp5YWJh
ZG9vPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iIGR0OnR5cGU9
InRpbWVJbnN0YW50Ij4yMDAwLTAzLTIzOjA3OjQxOjM0LTA1OjAwPC9tYTpDbG9zZT48bWE6T3Bl
biB4bWxuczpkdD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOm1hPSJo
dHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93
d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5j
b20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxl
LmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iIGR0OnR5cGU9InRpbWVJbnN0YW50Ij4yMDAwLTAz
LTE5OjE3OjAzOjAwLTA0OjAwPC9tYTpPcGVuPjxtYTpDbG9zZSB4bWxuczpkdD0iaHR0cDovL3d3
dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29t
L0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsi
IHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9u
ZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNo
YmF5IiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI3lh
YmFkb28iIGR0OnR5cGU9InRpbWVJbnN0YW50Ij4yMDAwLTAzLTI5OjE3OjAzOjAwLTA0OjAwPC9t
YTpDbG9zZT48L1EzPgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKLS0tCj4gPFEzPjxtYTpP
cGVuIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55
em9uZSIgeG1sbnM6ZHQ9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczpl
YWNoYmF5PSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2VhY2hiYXkiIHhtbG5z
Om1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0
dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhh
bXBsZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyIgZHQ6dHlwZT0idGltZUluc3RhbnQiPjIwMDAt
MDMtMjE6MDc6NDE6MzQtMDU6MDA8L21hOk9wZW4+PG1hOkNsb3NlIHhtbG5zOmFueXpvbmU9Imh0
dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZHQ9Imh0dHA6
Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczplYWNoYmF5PSJodHRwOi8vd3d3LmV4
YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2VhY2hiYXkiIHhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkv
eGxpbmsiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMj
eWFiYWRvbyIgZHQ6dHlwZT0idGltZUluc3RhbnQiPjIwMDAtMDMtMjM6MDc6NDE6MzQtMDU6MDA8
L21hOkNsb3NlPjxtYTpPcGVuIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20v
YXVjdGlvbmVlcnMjYW55em9uZSIgIHhtbG5zOmR0PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hN
TFNjaGVtYSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVy
cyNlYWNoYmF5InhtbG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIg
eG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOnlhYmFkb289
Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyIgZHQ6dHlwZT0idGlt
ZUluc3RhbnQiPjIwMDAtMDMtMTk6MTc6MDM6MDAtMDQ6MDA8L21hOk9wZW4+PG1hOkNsb3NlIHht
bG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIg
eG1sbnM6ZHQ9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczplYWNoYmF5
PSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2VhY2hiYXkiIHhtbG5zOm1hPSJo
dHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93
d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhhbXBsZS5j
b20vYXVjdGlvbmVlcnMjeWFiYWRvbyIgZHQ6dHlwZT0idGltZUluc3RhbnQiPjIwMDAtMDMtMjk6
MTc6MDM6MDAtMDQ6MDA8L21hOkNsb3NlPjwvUTM+ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmls
ZQpJbmRleDogLi9FeHBlY3RlZFRlc3RSZXN1bHRzL1VzZUNhc2UvVXNlQ2FzZU5TL25zLXF1ZXJp
ZXMtcmVzdWx0cy1xNS50eHQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3NvdXJjZXMvcHVibGljLzIw
MDYveHF1ZXJ5LXRlc3Qtc3VpdGUvVGVzdFN1aXRlU3RhZ2luZ0FyZWEvRXhwZWN0ZWRUZXN0UmVz
dWx0cy9Vc2VDYXNlL1VzZUNhc2VOUy9ucy1xdWVyaWVzLXJlc3VsdHMtcTUudHh0LHYKcmV0cmll
dmluZyByZXZpc2lvbiAxLjUKZGlmZiAtcjEuNSBucy1xdWVyaWVzLXJlc3VsdHMtcTUudHh0CjFj
MQo8IDxRNSB4bWxuczptdXNpYz0iaHR0cDovL3d3dy5leGFtcGxlLm9yZy9tdXNpYy9yZWNvcmRz
Ij48cmVjb3JkIHhtbG5zPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL211c2ljL3JlY29yZHMiIHht
bG5zOm1hPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9
Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cu
ZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3
dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRwOi8v
d3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI3lhYmFkb28iPgotLS0KPiA8UTUgeG1sbnM6bXVz
aWM9Imh0dHA6Ly93d3cuZXhhbXBsZS5vcmcvbXVzaWMvcmVjb3JkcyI+PHJlY29yZCB4bWxucz0i
aHR0cDovL3d3dy5leGFtcGxlLm9yZy9tdXNpYy9yZWNvcmRzIiB4bWxuczphbnl6b25lPSJodHRw
Oi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2FueXpvbmUiIHhtbG5zOmVhY2hiYXk9Imh0
dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjZWFjaGJheSIgeG1sbnM6bWE9Imh0dHA6
Ly93d3cuZXhhbXBsZS5jb20vQXVjdGlvbldhdGNoIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53
My5vcmcvMTk5OS94bGluayIgeG1sbnM6eWFiYWRvbz0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9h
dWN0aW9uZWVycyN5YWJhZG9vIj4KSW5kZXg6IC4vRXhwZWN0ZWRUZXN0UmVzdWx0cy9Vc2VDYXNl
L1VzZUNhc2VOUy9ucy1xdWVyaWVzLXJlc3VsdHMtcTYudHh0Cj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6
IC9zb3VyY2VzL3B1YmxpYy8yMDA2L3hxdWVyeS10ZXN0LXN1aXRlL1Rlc3RTdWl0ZVN0YWdpbmdB
cmVhL0V4cGVjdGVkVGVzdFJlc3VsdHMvVXNlQ2FzZS9Vc2VDYXNlTlMvbnMtcXVlcmllcy1yZXN1
bHRzLXE2LnR4dCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zCmRpZmYgLXIxLjMgbnMtcXVlcmll
cy1yZXN1bHRzLXE2LnR4dAoxYzEKPCA8UTYgeG1sbnM6bWE9Imh0dHA6Ly93d3cuZXhhbXBsZS5j
b20vQXVjdGlvbldhdGNoIj48bWE6Q2xvc2UgeG1sbnM6ZHQ9Imh0dHA6Ly93d3cudzMub3JnLzIw
MDEvWE1MU2NoZW1hIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIg
eG1sbnM6YW55em9uZT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNhbnl6b25l
IiB4bWxuczplYWNoYmF5PSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2VhY2hi
YXkiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjeWFi
YWRvbyIgZHQ6dHlwZT0idGltZUluc3RhbnQiPjIwMDAtMDMtMjM6MDc6NDE6MzQtMDU6MDA8L21h
OkNsb3NlPjwvUTY+ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQotLS0KPiA8UTYgeG1sbnM6
bWE9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vQXVjdGlvbldhdGNoIj48bWE6Q2xvc2UgeG1sbnM6
YW55em9uZT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNhbnl6b25lIiB4bWxu
czpkdD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOmVhY2hiYXk9Imh0
dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjZWFjaGJheSIgeG1sbnM6eGxpbms9Imh0
dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhh
bXBsZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyIgZHQ6dHlwZT0idGltZUluc3RhbnQiPjIwMDAt
MDMtMjM6MDc6NDE6MzQtMDU6MDA8L21hOkNsb3NlPjwvUTY+ClwgTm8gbmV3bGluZSBhdCBlbmQg
b2YgZmlsZQpJbmRleDogLi9FeHBlY3RlZFRlc3RSZXN1bHRzL1VzZUNhc2UvVXNlQ2FzZU5TL25z
LXF1ZXJpZXMtcmVzdWx0cy1xNy50eHQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3NvdXJjZXMvcHVi
bGljLzIwMDYveHF1ZXJ5LXRlc3Qtc3VpdGUvVGVzdFN1aXRlU3RhZ2luZ0FyZWEvRXhwZWN0ZWRU
ZXN0UmVzdWx0cy9Vc2VDYXNlL1VzZUNhc2VOUy9ucy1xdWVyaWVzLXJlc3VsdHMtcTcudHh0LHYK
cmV0cmlldmluZyByZXZpc2lvbiAxLjQKZGlmZiAtcjEuNCBucy1xdWVyaWVzLXJlc3VsdHMtcTcu
dHh0CjFjMQo8IDxRNyB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayI+
PG1hOkF1Y3Rpb25Ib21lcGFnZSB4bWxuczptYT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9BdWN0
aW9uV2F0Y2giIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVl
cnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hdWN0aW9u
ZWVycyNlYWNoYmF5IiB4bWxuczp5YWJhZG9vPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rp
b25lZXJzI3lhYmFkb28iIHhsaW5rOnR5cGU9InNpbXBsZSIgeGxpbms6aHJlZj0iaHR0cDovL2F1
Y3Rpb25zLnlhYmFkb28uY29tL2F1Y3Rpb24vMTMxNDM4MTYiLz48L1E3PgpcIE5vIG5ld2xpbmUg
YXQgZW5kIG9mIGZpbGUKLS0tCj4gPFE3IHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8x
OTk5L3hsaW5rIj48bWE6QXVjdGlvbkhvbWVwYWdlIHhtbG5zOmFueXpvbmU9Imh0dHA6Ly93d3cu
ZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjYW55em9uZSIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3
dy5leGFtcGxlLmNvbS9hdWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczptYT0iaHR0cDovL3d3dy5l
eGFtcGxlLmNvbS9BdWN0aW9uV2F0Y2giIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhhbXBs
ZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyIgeGxpbms6dHlwZT0ic2ltcGxlIiB4bGluazpocmVm
PSJodHRwOi8vYXVjdGlvbnMueWFiYWRvby5jb20vYXVjdGlvbi8xMzE0MzgxNiIvPjwvUTc+Clwg
Tm8gbmV3bGluZSBhdCBlbmQgb2YgZmlsZQpJbmRleDogLi9FeHBlY3RlZFRlc3RSZXN1bHRzL1Vz
ZUNhc2UvVXNlQ2FzZU5TL25zLXF1ZXJpZXMtcmVzdWx0cy1xOC50eHQKPT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1Mg
ZmlsZTogL3NvdXJjZXMvcHVibGljLzIwMDYveHF1ZXJ5LXRlc3Qtc3VpdGUvVGVzdFN1aXRlU3Rh
Z2luZ0FyZWEvRXhwZWN0ZWRUZXN0UmVzdWx0cy9Vc2VDYXNlL1VzZUNhc2VOUy9ucy1xdWVyaWVz
LXJlc3VsdHMtcTgudHh0LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjMKZGlmZiAtcjEuMyBucy1x
dWVyaWVzLXJlc3VsdHMtcTgudHh0CjFjMQo8IDxROCB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53
My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZWFjaGJheT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9h
dWN0aW9uZWVycyNlYWNoYmF5IiB4bWxuczptYT0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9BdWN0
aW9uV2F0Y2giPjxtYTpIaWdoX0JpZGRlciB4bWxuczphbnl6b25lPSJodHRwOi8vd3d3LmV4YW1w
bGUuY29tL2F1Y3Rpb25lZXJzI2FueXpvbmUiIHhtbG5zOnlhYmFkb289Imh0dHA6Ly93d3cuZXhh
bXBsZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyI+Ci0tLQo+IDxROCB4bWxuczplYWNoYmF5PSJo
dHRwOi8vd3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2VhY2hiYXkiIHhtbG5zOm1hPSJodHRw
Oi8vd3d3LmV4YW1wbGUuY29tL0F1Y3Rpb25XYXRjaCIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cu
dzMub3JnLzE5OTkveGxpbmsiPjxtYTpIaWdoX0JpZGRlciB4bWxuczphbnl6b25lPSJodHRwOi8v
d3d3LmV4YW1wbGUuY29tL2F1Y3Rpb25lZXJzI2FueXpvbmUiIHhtbG5zOnlhYmFkb289Imh0dHA6
Ly93d3cuZXhhbXBsZS5jb20vYXVjdGlvbmVlcnMjeWFiYWRvbyI+Cg==
</data>

          </attachment>
      

    </bug>

</bugzilla>