xerces-2_11_0/ 40755 0 0 0 11474015643 10265 5ustar 0 0 xerces-2_11_0/data/ 40755 0 0 0 11474015641 11174 5ustar 0 0 xerces-2_11_0/docs/ 40755 0 0 0 11474015642 11214 5ustar 0 0 xerces-2_11_0/docs/dtd/ 40755 0 0 0 11474015642 11767 5ustar 0 0 xerces-2_11_0/docs/style/ 40755 0 0 0 11474015642 12354 5ustar 0 0 xerces-2_11_0/docs/style/graphics/ 40755 0 0 0 11474015642 14154 5ustar 0 0 xerces-2_11_0/docs/style/resources/ 40755 0 0 0 11474015642 14366 5ustar 0 0 xerces-2_11_0/docs/style/stylesheets/ 40755 0 0 0 11474015642 14730 5ustar 0 0 xerces-2_11_0/samples/ 40755 0 0 0 11474015643 11731 5ustar 0 0 xerces-2_11_0/samples/dom/ 40755 0 0 0 11474015643 12510 5ustar 0 0 xerces-2_11_0/samples/dom/traversal/ 40755 0 0 0 11474015643 14513 5ustar 0 0 xerces-2_11_0/samples/dom/wrappers/ 40755 0 0 0 11474015643 14353 5ustar 0 0 xerces-2_11_0/samples/jaxp/ 40755 0 0 0 11474015643 12673 5ustar 0 0 xerces-2_11_0/samples/sax/ 40755 0 0 0 11474015643 12524 5ustar 0 0 xerces-2_11_0/samples/sax/helpers/ 40755 0 0 0 11474015642 14165 5ustar 0 0 xerces-2_11_0/samples/simpletype/ 40755 0 0 0 11474015643 14124 5ustar 0 0 xerces-2_11_0/samples/socket/ 40755 0 0 0 11474015643 13221 5ustar 0 0 xerces-2_11_0/samples/socket/io/ 40755 0 0 0 11474015643 13630 5ustar 0 0 xerces-2_11_0/samples/ui/ 40755 0 0 0 11474015643 12346 5ustar 0 0 xerces-2_11_0/samples/xni/ 40755 0 0 0 11474015643 12527 5ustar 0 0 xerces-2_11_0/samples/xni/parser/ 40755 0 0 0 11474015643 14023 5ustar 0 0 xerces-2_11_0/samples/xs/ 40755 0 0 0 11474015642 12362 5ustar 0 0 xerces-2_11_0/src/ 40755 0 0 0 11474015637 11057 5ustar 0 0 xerces-2_11_0/src/org/ 40755 0 0 0 11474015633 11642 5ustar 0 0 xerces-2_11_0/src/org/apache/ 40755 0 0 0 11474015632 13062 5ustar 0 0 xerces-2_11_0/src/org/apache/html/ 40755 0 0 0 11474015632 14026 5ustar 0 0 xerces-2_11_0/src/org/apache/html/dom/ 40755 0 0 0 11474015641 14605 5ustar 0 0 xerces-2_11_0/src/org/apache/wml/ 40755 0 0 0 11474015641 13661 5ustar 0 0 xerces-2_11_0/src/org/apache/wml/dom/ 40755 0 0 0 11474015641 14440 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/ 40755 0 0 0 11474015633 14354 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/dom/ 40755 0 0 0 11474015641 15132 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/dom3/ 40755 0 0 0 11474015633 15216 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/dom3/as/ 40755 0 0 0 11474015640 15617 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/dom/events/ 40755 0 0 0 11474015641 16436 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/ 40755 0 0 0 11474015640 15313 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dtd/ 40755 0 0 0 11474015641 16067 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dtd/models/ 40755 0 0 0 11474015640 17351 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dv/ 40755 0 0 0 11474015641 15725 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dv/dtd/ 40755 0 0 0 11474015640 16477 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dv/util/ 40755 0 0 0 11474015637 16707 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/dv/xs/ 40755 0 0 0 11474015641 16357 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/io/ 40755 0 0 0 11474015637 15730 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/msg/ 40755 0 0 0 11474015640 16101 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/validation/ 40755 0 0 0 11474015637 17453 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xpath/ 40755 0 0 0 11474015634 16442 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xpath/regex/ 40755 0 0 0 11474015640 17551 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/ 40755 0 0 0 11474015641 15746 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/identity/ 40755 0 0 0 11474015637 17604 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/models/ 40755 0 0 0 11474015641 17231 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/opti/ 40755 0 0 0 11474015641 16721 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/traversers/ 40755 0 0 0 11474015641 20146 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/impl/xs/util/ 40755 0 0 0 11474015640 16722 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/jaxp/ 40755 0 0 0 11474015641 15315 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/jaxp/datatype/ 40755 0 0 0 11474015641 17130 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/jaxp/validation/ 40755 0 0 0 11474015640 17446 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/parsers/ 40755 0 0 0 11474015641 16032 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/stax/ 40755 0 0 0 11474015641 15332 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/stax/events/ 40755 0 0 0 11474015640 16635 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/util/ 40755 0 0 0 11474015641 15330 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xinclude/ 40755 0 0 0 11474015641 16166 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xni/ 40755 0 0 0 11474015641 15151 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xni/grammars/ 40755 0 0 0 11474015641 16762 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xni/parser/ 40755 0 0 0 11474015641 16445 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xpointer/ 40755 0 0 0 11474015641 16223 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xs/ 40755 0 0 0 11474015641 15005 5ustar 0 0 xerces-2_11_0/src/org/apache/xerces/xs/datatypes/ 40755 0 0 0 11474015641 17003 5ustar 0 0 xerces-2_11_0/src/org/apache/xml/ 40755 0 0 0 11474015632 13662 5ustar 0 0 xerces-2_11_0/src/org/apache/xml/serialize/ 40755 0 0 0 11474015641 15651 5ustar 0 0 xerces-2_11_0/src/org/w3c/ 40755 0 0 0 11474015633 12336 5ustar 0 0 xerces-2_11_0/src/org/w3c/dom/ 40755 0 0 0 11474015633 13115 5ustar 0 0 xerces-2_11_0/src/org/w3c/dom/html/ 40755 0 0 0 11474015633 14061 5ustar 0 0 xerces-2_11_0/LICENSE100644 0 0 26450 11474015643 11416 0ustar 0 0 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. xerces-2_11_0/LICENSE-SAX.html100644 0 0 664 11474015643 12751 0ustar 0 0 SAX LICENSE

This license applies to all interfaces and classes in the org/xml/sax hierarchy.

This module, both source code and documentation, is in the Public Domain, and comes with NO WARRANTY. See http://www.saxproject.org for further information.

xerces-2_11_0/LICENSE.DOM-documentation.html100644 0 0 11637 11474015643 15647 0ustar 0 0 W3C Document License

W3C® DOCUMENT LICENSE

http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231

Public documents on the W3C site are provided by the copyright holders under the following license. By using and/or copying this document, or the W3C document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:

Permission to copy, and distribute the contents of this document, or the W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:

  1. A link or URL to the original W3C document.
  2. The pre-existing copyright notice of the original author, or if it doesn't exist, a notice (hypertext is preferred, but a textual representation is permitted) of the form: "Copyright © [$date-of-document] World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231"
  3. If it exists, the STATUS of the W3C document.

When space permits, inclusion of the full text of this NOTICE should be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.

No right to create modifications or derivatives of W3C documents is granted pursuant to this license. However, if additional requirements (documented in the Copyright FAQ) are satisfied, the right to create modifications or derivatives is sometimes granted by the W3C to individuals complying with those requirements.

THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.

----------------------------------------------------------------------------

This formulation of W3C's notice and license became active on December 31 2002. This version removes the copyright ownership notice such that this license can be used with materials other than those owned by the W3C, moves information on style sheets, DTDs, and schemas to the Copyright FAQ, reflects that ERCIM is now a host of the W3C, includes references to this specific dated version of the license, and removes the ambiguous grant of "use". See the older formulation for the policy prior to this date. Please see our Copyright FAQ for common questions about using materials from our site, such as the translating or annotating specifications. Other questions about this notice can be directed to site-policy@w3.org.

Joseph Reagle <mailto:site-policy@w3.org

Last revised by Reagle $Date: 2004-04-06 13:20:26 -0400 (Tue, 06 Apr 2004) $

xerces-2_11_0/LICENSE.DOM-software.html100644 0 0 10107 11474015643 14617 0ustar 0 0 W3C IPR SOFTWARE NOTICE

W3C SOFTWARE NOTICE AND LICENSE

Copyright © 2004 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved.

The DOM bindings are published under the W3C Software Copyright Notice and License. The software license requires "Notice of any changes or modifications to the W3C files, including the date changes were made." Consequently, modified versions of the DOM bindings must document that they do not conform to the W3C standard; in the case of the IDL definitions, the pragma prefix can no longer be 'w3c.org'; in the case of the Java language binding, the package names can no longer be in the 'org.w3c' package.

Note: The original version of the W3C Software Copyright Notice and License could be found at http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231

This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.

Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications:

  1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
  2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software Short Notice should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code.
  3. Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.)

THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION.

The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders.

xerces-2_11_0/LICENSE.resolver.txt100644 0 0 26446 11474015643 14101 0ustar 0 0 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. xerces-2_11_0/LICENSE.serializer.txt100644 0 0 26446 11474015643 14411 0ustar 0 0 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. xerces-2_11_0/NOTICE100644 0 0 1617 11474015643 11273 0ustar 0 0 ========================================================================= == NOTICE file corresponding to section 4(d) of the Apache License, == == Version 2.0, in this case for the Apache Xerces Java distribution. == ========================================================================= Apache Xerces Java Copyright 1999-2010 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Portions of this software were originally based on the following: - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. - voluntary contributions made by Paul Eng on behalf of the Apache Software Foundation that were originally developed at iClick, Inc., software copyright (c) 1999.xerces-2_11_0/NOTICE.resolver.txt100644 0 0 604 11474015643 13724 0ustar 0 0 Apache XML Commons Resolver Copyright 2006 The Apache Software Foundation. This product includes software developed at The Apache Software Foundation http://www.apache.org/ Portions of this code are derived from classes placed in the public domain by Arbortext on 10 Apr 2000. See: http://www.arbortext.com/customer_support/updates_and_technical_notes/catalogs/docs/README.htm xerces-2_11_0/NOTICE.serializer.txt100644 0 0 1540 11474015643 14254 0ustar 0 0 ========================================================================= == NOTICE file corresponding to section 4(d) of the Apache License, == == Version 2.0, in this case for the Apache Xalan Java distribution. == ========================================================================= Apache Xalan (Xalan serializer) Copyright 1999-2006 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Portions of this software was originally based on the following: - software copyright (c) 1999-2002, Lotus Development Corporation., http://www.lotus.com. - software copyright (c) 2001-2002, Sun Microsystems., http://www.sun.com. - software copyright (c) 2003, IBM Corporation., http://www.ibm.com. xerces-2_11_0/README100644 0 0 5071 11474015643 11245 0ustar 0 0 Xerces Java Build Instructions ------------------------------ =========================================================================== * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. =========================================================================== Before building Xerces, you need the source package and tools package available from the Apache XML Project's distribution web page: http://xml.apache.org/dist/xerces-j/ Download both the Xerces-J-src.X.Y.Z.zip and Xerces-J-tools.X.Y.Z.zip files for the appropriate Xerces release (where "X.Y.Z" is the version number) and extract them in the same directory. If you are using Unix, download the equivalent .tar.gz files instead of the .zip files. You also need to have a Java Development Kit (JDK) version 1.2 (or higher) installed on your system. Before initiating any part of the build, set the JAVA_HOME environment variable to the installation directory of your JDK. The Ant program is used to build everything in Xerces, including the documentation. This tool, and the others needed (besides the pre-requisite JDK) are contained within the tools package. To make building the packages easier, a Windows batch file and a Unix shell script are included. If you only want to compile the source code and make the JAR files, run the following command on Windows: build.bat jars or from Unix (make sure that build.sh is executable): build.sh jars This will compile all of the source code and generate the JAR files that are available as part of the binary package. After building, these files will be located in the build/ directory. If you want to build everything, including the documentation, run the build batch file (or shell script) specifying the "all" target instead of "jars".xerces-2_11_0/Readme.html100644 0 0 3176 11474015643 12454 0ustar 0 0 Xerces Java Parser

Xerces Java Parser

Redirecting to Documentation...

In a few seconds, you should be redirected to the Xerces Java Parser documentation. If you are not automatically redirected, please click on the following link:

Xerces Java Documentation

Note: You must download the binary distribution to get the documentation. If you downloaded the source distribution, then you must build the documentation first.

xerces-2_11_0/build.bat100644 0 0 4272 11474015643 12156 0ustar 0 0 @echo off rem rem ========================================================================== rem = Licensed to the Apache Software Foundation (ASF) under one or more rem = contributor license agreements. See the NOTICE file distributed with rem = this work for additional information regarding copyright ownership. rem = The ASF licenses this file to You under the Apache License, Version 2.0 rem = (the "License"); you may not use this file except in compliance with rem = the License. You may obtain a copy of the License at rem = rem = http://www.apache.org/licenses/LICENSE-2.0 rem = rem = Unless required by applicable law or agreed to in writing, software rem = distributed under the License is distributed on an "AS IS" BASIS, rem = WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. rem = See the License for the specific language governing permissions and rem = limitations under the License. rem ========================================================================== rem echo Xerces-Java Build System echo ------------------------ if "%JAVA_HOME%" == "" goto error rem Keep this classpath to the minimum required to run ant rem Application dependent classpaths are specified in build.xml set LOCALCLASSPATH=%JAVA_HOME%\lib\tools.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%JAVA_HOME%\lib\classes.zip set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\ant.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\ant-nodeps.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\ant-launcher.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\ant-junit.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\xml-apis.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\xercesImpl.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;.\tools\bin\xjavac.jar echo Building with ant classpath %LOCALCLASSPATH% echo Starting Ant... "%JAVA_HOME%\bin\java.exe" -Dant.home="./tools" -classpath "%LOCALCLASSPATH%" org.apache.tools.ant.Main %1 %2 %3 %4 %5 goto end :error echo "ERROR: JAVA_HOME not found in your environment." echo "Please, set the JAVA_HOME variable in your environment to match the" echo "location of the Java Virtual Machine you want to use." :end set LOCALCLASSPATH= @echo on xerces-2_11_0/build.sh100644 0 0 4725 11474015643 12025 0ustar 0 0 #!/bin/sh # #========================================================================= # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. #========================================================================= # echo echo "Xerces-Java Build System" echo "------------------------" if [ "$JAVA_HOME" = "" ] ; then echo "ERROR: JAVA_HOME not found in your environment." echo echo "Please, set the JAVA_HOME variable in your environment to match the" echo "location of the Java Virtual Machine you want to use." exit 1 fi # OS specific support. $var _must_ be set to either true or false. cygwin=false; case "`uname`" in CYGWIN*) cygwin=true ;; esac # For Cygwin, ensure paths are in UNIX format before anything is touched if $cygwin ; then [ -n "$JAVA_HOME" ] && JAVA_HOME=`cygpath --unix "$JAVA_HOME"` fi LIBDIR=./tools ANT_HOME="$LIBDIR" LOCALCLASSPATH="$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/ant.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/ant-nodeps.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/ant-launcher.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/ant-junit.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/xml-apis.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/xercesImpl.jar" LOCALCLASSPATH="$LOCALCLASSPATH:$LIBDIR/bin/xjavac.jar" # For Cygwin, switch paths to Windows format before running java if $cygwin; then JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"` LOCALCLASSPATH=`cygpath --path --windows "$LOCALCLASSPATH"` fi echo echo Building with classpath $LOCALCLASSPATH echo Starting Ant... echo "$JAVA_HOME"/bin/java -Dant.home="$ANT_HOME" -classpath "$LOCALCLASSPATH" org.apache.tools.ant.Main $@ xerces-2_11_0/build.xml100644 0 0 236214 11474015643 12253 0ustar 0 0

INTERNAL:

Usage of this class is not supported. It may be altered or removed at any time.
]]>

EXPERIMENTAL:

This class should not be considered stable. It is likely to be altered or replaced in the future.
]]> xerces-2_11_0/data/personal-schema.xml100644 0 0 2337 11474015641 15101 0ustar 0 0 Boss Big chief@foo.com Worker One one@foo.com Worker Two two@foo.com Worker Three three@foo.com Worker Four four@foo.com Worker Five five@foo.com xerces-2_11_0/data/personal.dtd100644 0 0 1204 11474015641 13606 0ustar 0 0 xerces-2_11_0/data/personal.xml100644 0 0 2242 11474015641 13636 0ustar 0 0 Boss Big chief@foo.com Worker One one@foo.com Worker Two two@foo.com Worker Three three@foo.com Worker Four four@foo.com Worker Five five@foo.com xerces-2_11_0/data/personal.xsd100644 0 0 4252 11474015641 13637 0ustar 0 0 xerces-2_11_0/docs/api.xml100644 0 0 15765 11474015641 12641 0ustar 0 0

Always try to use only the standard XML APIs when writing XML applications. This will keep your application shielded from changes in the underlying implementation of those standard APIs and also gives you more flexibility to change the implementation of the standard pieces without modifying your application code.

If you need functionality that is not available in the standard APIs like DOM and SAX, then perhaps using the Xerces Native Interface (XNI) will provide the information to build the appropriate parsing tools for your application. For more detailed information regarding XNI, refer to the XNI Manual.

The XML Schema API specification defines a set of interfaces for accessing and querying the post schema validation infoset (PSVI) defined in Contributions to the post-schema-validation infoset (Appendix C.2). These interfaces provide access to the XML Schema components, which follow as a consequence of validation and/or assessment and also provide a means for accessing the PSVI from a document instance.

Some of the interfaces in the XML Schema API reference interfaces from DOM Level 3 which is now a W3C Recommendation.

  • XML Schema API

For maintainers and developers of the Xerces2 reference implementation, it's important to know the internal APIs used.

  • Xerces2 Implementation

The Xerces2 package also contains other implementation classes. You can jump to the API for these classes via the following links:

  • Other Classes
 xerces-2_11_0/docs/bugzilla.xml100644 0 0 5471 11474015642 13653 0ustar 0 0

Before you report a bug, please, read the following instructions:

We strongly encourage you write patches for problems you find and submit them to j-dev@xerces.apache.org. Being specific in the description of your bug report, and providing enough information to reproduce the bug will improve the likelihood that the bug you found will be fixed in the foreseeable future. In the interest of fixing bugs, adding enhancements, and addressing outstanding design issues, we need your active participation in the ongoing development of Xerces2.

Have you read the instructions above? If yes, please click here to submit a bug report.

xerces-2_11_0/docs/charter.xml100644 0 0 41712 11474015642 13510 0ustar 0 0

The following charter applies to all Xerces projects.

1.1 Apache Xerces is a collaborative software development project dedicated to providing robust, full-featured, commercial-quality, and freely available XML parsers and closely related technologies on a wide variety of platforms supporting several languages. This project is managed in cooperation with various individuals worldwide (both independent and company-affiliated experts), who use the Internet to communicate, plan, and develop XML software and related documentation.

1.2 This charter briefly describes the mission, history, organization, and processes of the project.

2.1 Apache Xerces exists to promote the use of XML. We view XML as a compelling paradigm that structures data as information, thereby facilitating the exchange, transformation, and presentation of knowledge. The ability to transform raw data into usable information has great potential to improve the functionality and use of information systems. We intend to build freely available XML parsers and closely related technologies in order to engender such improvements.

2.2 The Apache Xerces parsers support standard APIs (formal, de facto, or proposed). They are designed to be high performance, reliable, and easy to use. To facilitate easy porting of ideas between languages, the API's supported should be as similar as possible, given the constraints of the languages and existing architectures. Apache Xerces parsers should also be designed to work efficiently with other Apache projects that deal with XML whenever possible.

2.3 We believe that the best way to further these goals is by having both individuals and corporations collaborate on the best possible infrastructure, APIs, code, testing, and release cycles. Components must be vendor neutral and usable as core components for all.

2.4 In order to achieve a coherent architecture between Apache Xerces parsers and other components and applications, standards (formal or de facto) will be used as much as possible for both protocols and APIs. Where appropriate, experiences and lessons learned will be fed back to standards bodies in an effort to assist in the development of those standards. We will also encourage the innovation of new protocols, APIs, and components in order to seed new concepts not yet defined by standards.

3.1 The code base which formed the foundations of both the Xerces-Java and Xerces-C++ subprojects of the Apache XML Project was originally donated to Apache by IBM in 1999. Xerces-Perl came into existence as a subproject of the Apache XML project after the Xerces-C++ community had already matured to a significant extent. All three were subprojects of the Apache XML Project until late 2004. At this time, reflecting the growth in the Apache XML project and these communities themselves, Apache Xerces became a top-level Project of the Apache Software Foundation. Apache Xerces still shares much infrastructure with the Apache XML project and the other former subprojects of Apache XML that have become projects in their own right.

4.1 The ASF Board. The management board of the Apache Software Foundation.

4.2 The Project. The Apache Xerces Project; intended to refer to the source code, website and community that are Apache Xerces.

4.3 Subproject. Apache Xerces is composed of a number of subprojects which fit into one of two categories:

a) An XML parser implementation in some particular programming language. There may be multiple parsers for a given language, if the API's the parsers support are sufficiently dissimilar. At the time of writing, there is one parser for each of Java, C/C++ and Perl.

b) A set of components serving some purpose not directly pertinent to XML parsing, but which are used in related applications and are tightly bound, usually through internal API's, to one (or more) of the parser subprojects.

4.4 Product. Some deliverable (usually a binary or source package) that a subproject releases to the public. Subprojects may have multiple products.

4.5 Contributor. Anyone who makes a contribution to the development of the Apache Xerces project or a subproject.

4.6 Committer. Apache Xerces has a set of committers. Committers are contributors who have read/write access to the source code repository.

5.1 The Apache Xerces project is managed by a core group of committers known as the Project Management Committee [PMC], which is composed of volunteers from among the active committers (see 8.3 below) from all subprojects. Each subproject must have at least one representative on the PMC, to ensure active supervision of the subproject.

5.2 The activities of the PMC are coordinated by the Chairperson, who is an officer of the corporation and reports to the Apache Board. The Chairperson will, on the request of the Apache Board, provide reports to the Board on issues related to the running of the Apache Xerces project.

5.3 The PMC has the following responsibilities:

a) Accepting new subproject proposals, voting on these proposals and creating the subproject (see SUBPROJECTS below). This is done in collaboration with the Incubator (see http://incubator.apache.org).

b) Facilitating code or other donations by individuals or companies, in collaboration with the Incubator.

c) Resolving license issues and other legal issues in conjunction with the ASF board.

d) Ensuring that administrative and infrastructure work is completed.

e) Facilitating relationships among subprojects and other Apache projects.

f) Facilitating relationships between Apache Xerces and the external world.

g) Overseeing Apache Xerces to ensure that the mission defined in this document is being fulfilled.

h) Resolving conflicts within the project.

i) Reporting to the ASF board (through the Chair) on the progress of the project.

5.4 In cases where the sub-project is unable to directly provide at least one representative on the PMC--implying that there are no active committers on that code base--then the subproject should be considered dormant, and any relevant Apache policies for dormant projects should be implemented. At the least, the subproject's status should be updated on its website.

5.5 Every 12 months, or at the request of the Board, the PMC will provide a recommendation to the Apache Board for the position of Chairperson of the PMC.

5.6 This recommendation will be made on the basis of an election held within the PMC. The election will be performed using a simple majority vote of PMC members.

5.7 Upon agreement by the Apache Board, the recommended Chairperson will, if they are not already, be appointed an officer of the corporation. See http://www.apache.org/foundation/bylaws.html for more information.

5.8 In the unlikely event that a member of the PMC becomes disruptive to the process, ceases to make codebase contributions for an extended period, or ceases to take part in PMC votes for an extended period of time, said member may be removed by unanimous vote of remaining PMC members.

5.9 The PMC is responsible for maintaining and updating this charter. Development must follow the process outlined below, so any change to the development process necessitates a change to the charter. Changes must be approved by a two-thirds majority of all members of the PMC.

6.1 When a new subproject proposal is submitted to the PMC, it may be accepted by a two-thirds vote of the PMC.

6.2 A subproject may be removed by unanimous vote of the PMC, subject to the approval of the ASF board.

7.1 Like all Apache projects, the Apache Xerces project is a meritocracy -- the more work you do, the more you are allowed to do. Contributions will include participating in mailing lists, reporting bugs, providing patches and proposing changes to a product.

7.2 In order to ensure that all code contained in the Apache Xerces project's code repository is free of licensing, intellectual property and patent issues, any developer wishing to contribute a new feature to Xerces must either sign:

a) If contributing as an individual, sign the "Individual Contributor License Agreement (CLA)" (http://www.apache.org/licenses/icla.txt) and file a copy with the Secretary of the Corporation; or

b) If making the contribution as part of their employment responsibilities, sign the "Corporate CLA (CCLA)", (http://www.apache.org/licenses/cla-corporate.txt) and file a copy with the Secretary of the Corporation.

7.3 If the contribution in question is a small bugfix, the contributor need not sign a CLA, but need only provide the following information, attaching it to the communication containing the patch:

a) Name and employer

b) Are you the author of the code being contributed?

c) Do you have the right to grant the copyright and patent licenses for the contribution that are set forth in the ASF v.2.0 license (http://www.apache.org/licenses/LICENSE-2.0)?

d) Does your employer have any rights to code that you have written, for example, through your contract for employment? If so, has your employer given you permission to contribute the code on its behalf or waived its rights in the code?

e) Are you aware of any third-party licenses or other restrictions (such as related patents or trademarks) that could apply to your contribution? If so, what are they?

7.4 Contributors who make regular and substantial contributions may become committers as described below.

8.1 Each subproject has a set of committers. Committers are contributors who have read/write access to the source code repository.

8.2 Normally, a new committer is added after a contributor has been nominated by a committer and approved by at least 50 percent of the active committers for that subproject with no opposing votes. In the case that a subproject has a very small number of active committers, the PMC may choose to require a PMC resolution to approve the nomination of a contributor by one of the active committers in that subproject. All committers must have a signed Contributor License Agreement on file with the Secretary of the Corporation. Since, in most cases, contributors will already have contributed significant amounts of code, this should usually have been done before nomination.

8.3 Although committers have write access to all Apache Xerces subprojects, they are only permitted to make changes to the subprojects to which they have been elected committers. A committer may be elected to multiple subprojects, but, except that no new access need be granted, the process is the same as for any other contributor.

8.4 For the purposes of voting, committers will be classed as "active" or "inactive". Only active committers will be included in the totals used to determine the success or failure of a particular vote, and only active committers are part of the PMC.

8.5 Committers remain active as long as they are contributing code or posting to the subproject mailing lists. If a committer has neither contributed code nor posted to the subproject mailing lists in 3 months, the PMC chair may e-mail the committer, the subproject development list, and the PMC mailing list notifying the committer that they are going to be moved to inactive status. If there is no response in 72 hours, the committer will become inactive, and may be removed from the PMC mailing list.

8.6 An inactive status will not prevent a committer committing new code changes or posting to the mailing lists. Either of these activities will automatically re-activate the committer for the purposes of voting, and necessitate their addition to the PMC mailing list.

9.1 The Apache Xerces project relies on the Apache XML project and the Apache Infrastructure project for the following:

a) Bug Database -- This is a system for tracking bugs and feature requests.

b) Subproject Source Repositories -- These are several repositories containing both the source code and documentation for the subprojects.

c) Website -- A xerces.apache.org website will contain information about the Apache Xerces project, including documentation, downloads of releases, and this charter. Each subproject will have its own website with subproject information.

d) PMC Mailing List -- This list is for PMC business requiring confidentiality, particularly when an individual or company requests discretion. All other PMC business should be done on the general mailing list.

e) General Mailing List -- This mailing list is open to the public. It is intended for discussions that cross subprojects.

f) Subproject Mailing Lists -- Each subproject should have at least one devoted mailing list. Many subprojects may wish to have both user and development lists. The individual subprojects may decide on the exact structure of their mailing lists.

10.1 All contributions to the Apache Xerces project adhere to the Apache Software Foundation License, v.2.0 (http://www.apache.org/licenses/LICENSE-2.0)? All further contributions must be made under the same terms.

10.2 When a committer is considering integrating a contribution from a contributor who has no CLA on file with the Corporation, it is the responsibility of the committer, in consultation with the PMC, to conduct due diligence on the pedigree of the contribution under consideration; see sections 7.2 and 7.3.

11.1 The development process is intentionally lightweight; like other Apache projects, the committers decide which changes may be committed to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a significant code change. For efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the committers.

12.1 Each subproject should have a set of requirements as well as an up-to-date release plan and design document on its dedicated web page.

12.2 It is recommended that each subproject have a smoke-test system that works at least as a basic integration test.

13.1 The Apache Xerces project should work closely with other Apache projects, such as XML, Jakarta and the Apache Server, to avoid redundancy and achieve a coherent architecture among Apache Xerces and these projects.

xerces-2_11_0/docs/docs-book.xml100644 0 0 12332 11474015641 13733 0ustar 0 0 xerces-2_11_0/docs/dom.xml100644 0 0 4210 11474015642 12607 0ustar 0 0

Xerces2 provides an implementation of the following W3C Document Object Model (DOM) Recommendations:

This section provides the following topics:

 xerces-2_11_0/docs/dom3.xml100644 0 0 12636 11474015642 12725 0ustar 0 0

The &ParserNameLong; &ParserVersion; contains an implementation of the Document Object Model Level 3 Core and Document Object Model Level 3 Load and Save Recommendations. To learn how to program with the DOM Level 3 see dom.DOM3 sample.

DOM Level 3 Core DOMConfiguration parameters supported are:

Additional DOM Level 3 Load and Save DOMConfiguration parameters supported:

Here is the list of DOM Level 3 Load and Save limitations:

 xerces-2_11_0/docs/download.cgi100644 0 0 360 11474015641 13562 0ustar 0 0 #!/bin/sh # Wrapper script around mirrors.cgi script # (we must change to that directory in order for python to pick up the # python includes correctly) cd /www/www.apache.org/dyn/mirrors /www/www.apache.org/dyn/mirrors/mirrors.cgi $*xerces-2_11_0/docs/download.xml100644 0 0 12407 11474015642 13666 0ustar 0 0

Use the links below to download the &ParserName; from one of our mirrors. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory.

You can download the &ParserName; distributions from the master distribution directory or, preferably, its mirror. Only current recommended releases are available on the main distribution site and its mirrors. Older releases are available from the archive download site.

The currently selected mirror is [preferred]. If you encounter a problem with this mirror, please select another mirror. If all mirrors are failing, there are backup mirrors (at the end of the mirrors list) that should be available.

Other mirrors:

You may also consult the complete list of mirrors.

It is essential that you verify the integrity of the downloaded files using the PGP or MD5 signatures. Please read Verifying HTTP Server Releases for more information on why you should verify our releases.

The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the asc signature file for the particular distribution. Make sure you get these files from the main distribution directory, rather than from a mirror. Then verify the signatures using

% pgpk -a KEYS % pgpv apache_1.3.24.tar.gz.asc

or

% pgp -ka KEYS % pgp apache_1.3.24.tar.gz.asc

or

% gpg --import KEYS % gpg --verify apache_1.3.24.tar.gz.asc

Alternatively, you can verify the MD5 signature on the files. A unix program called md5 or md5sum is included in many unix distributions. It is also available as part of GNU Textutils. Windows users can get binary md5 programs from here, here, or here.

 xerces-2_11_0/docs/dtd/blocks.ent100644 0 0 2510 11474015642 14047 0ustar 0 0 %markupEntity; xerces-2_11_0/docs/dtd/book.dtd100644 0 0 3561 11474015642 13520 0ustar 0 0 %externalEntity; xerces-2_11_0/docs/dtd/characters.ent100644 0 0 101025 11474015642 14752 0ustar 0 0 xerces-2_11_0/docs/dtd/design.dtd100644 0 0 4606 11474015642 14040 0ustar 0 0 xerces-2_11_0/docs/dtd/document.dtd100644 0 0 1017 11474015642 14376 0ustar 0 0 %blocksEntity; xerces-2_11_0/docs/dtd/entities.ent100644 0 0 1121 11474015642 14413 0ustar 0 0 xerces-2_11_0/docs/dtd/faqs.dtd100644 0 0 662 11474015642 13477 0ustar 0 0 %blocksEntity; xerces-2_11_0/docs/dtd/links.ent100644 0 0 1265 11474015642 13720 0ustar 0 0 xerces-2_11_0/docs/dtd/markup.ent100644 0 0 1256 11474015641 14076 0ustar 0 0 %externalEntity; %charEntity; %linksEntity; xerces-2_11_0/docs/dtd/releases.dtd100644 0 0 1167 11474015642 14371 0ustar 0 0 %include.blocks; xerces-2_11_0/docs/dtd/settings.dtd100644 0 0 2576 11474015641 14432 0ustar 0 0 %include.blocks; xerces-2_11_0/docs/faq-build.xml100644 0 0 35314 11474015642 13725 0ustar 0 0 Which version of Swing is required?

This release uses Swing 1.1 (JFC 1.1). Swing is only used by the sample programs and is not required by the parser itself.

How do I recompile the source files?

To build &ParserName; you need the Java Development Kit (JDK) version 1.3 (or higher) installed on your machine. The actual build is performed by the Ant program which is written in Java and is a subproject of the Apache Ant project. The build also requires a few other tools but all of the tools you need (including Ant) are contained in the &ParserName;-tools.&parserversion;.zip file, packaged separately. Go to the &ParserName; download page to download the tools package and then extract it in the same location as the source package.

Once you have extracted both the source and tools packages in the same directory, you can invoke a build by either using the "build.bat" file for Windows platforms or the "build.sh" file for UNIX platforms. Before invoking either one of these scripts, though, be sure to set the JAVA_HOME environment variable to the installed location of your JDK.

The script will invoke the Ant build program for you which displays the list of allowed build targets. To only compile the source files, type "build compile" (on Windows platforms) at the command line in the directory where you extracted &ParserName;; to build the Jar files, type "build jars"; and to build everything, including documentation, type "build all".

How do I regenerate the API documentation?

To regenerate the API documentation, you need to set up your environment to build &ParserName;. Instead of typing "build all", you type "build javadocs".

How do I import &ParserName; into Visual Age for Java
  • Why does VisualAge for Java 2.0 report problems when I import the &ParserName; parser?
    The current version of the &ParserName; parser uses Swing 1.1, while VisualAge for Java 2.0 comes with Swing 1.0.2. The free update for the Professional version of VisualAge for Java 2.0 installs Swing 1.0.3. The most important difference between Swing 1.0.2 - 1.0.3 and 1.1 is the Java package was changed from com.sun.java.swing.* to javax.swing.*.
    To fix the errors, you must download the Java Foundation Classes 1.1 with Swing 1.1 from Sun's Java home page and import the "swingall.jar" file into VisualAge for Java 2.0. The Swing 1.1 package can be found at the following URL:
    http://java.sun.com/products/jfc/index.html
    Refer to the VisualAge for Java 2.0 documentation for information about how to import a JAR file into the repository and add that code to your workspace.
  • Are there any other tips for importing the &ParserName; parser into VisualAge for Java 2.0?
    The most useful tip applies to any updated code that you import into the VisualAge for Java 2.0 product. Before updating code, do the following:
    1. version the old code
    2. delete it from your workspace
    3. import the new code
    Deleting code from your workspace does not actually delete the code permanently - the versioned code is moved to the repository where it can be retrieved later. Be aware, though, that removing code from your workspace will cause problems with all of the other classes that use that code. VisualAge for Java 2.0 will flag them as errors but this situation is temporary. When you import the new code, the errors found when deleting the old code will be fixed.
    If you are unsure as to how to perform any of these steps, refer to the VisualAge for Java 2.0 documentation.
How do I get &ParserName; to run on the Mac under MRJ?

Prerequisites (available from http://developer.apple.com/java/):

  • MRJ 2.1 (this is the most recent version of the JVM)
  • MRJ SDK 2.1 (this is the most recent version of the Java developer tools)

Instructions (other variations would work also):

  1. Download the .tar.gz file containing &ParserName;.
  2. Use Stuffit Expander(tm), Suntar, or some other Macintosh tool that supports the .tar.gz format to expand the downloaded file.
  3. JBindery, part of MRJ SDK 2.1, is used to create a double-clickable Java application with the necessary configuration information built in. It is analogous to writing a .bat or .sh script.
  4. To run the dom.DOMWriter example:
    1. Double click on JBindery to start it up.
    2. Click on the Classpath panel.
    3. Click on the "Add .zip File" button and add both the "xerces.jar" and "xercesSamples.jar" files.
    4. Click on the Command panel.
    5. Enter "dom.Writer" as the Class name. Enter "data/personal.xml" in the Optional parameters box.
    6. Click on Save Settings button, pick a name such as "Run dom.Writer" for the file, and be sure that "Save as Application" is selected (this is the default) and save the file.
    7. Quit JBindery.
    8. You can now double click on the file you created in step (f) to run the XJParse example.
Why do I get an ArrayIndexOutOfBoundsException in the Symantec Visual Cafe debugger?

The Visual Cafe debugger is set to trap ArrayIndexOutOfBoundsException exceptions by default. &ParserName; sometimes uses ArrayIndexOutOfBoundsException internally to signal exceptional, but not erroneous conditions. In order to run &ParserName; inside Visual Cafe's debugger, you need to turn off the trapping of these exceptions.

To do this:

  1. Select the "Options" item in the "Project" menu.
  2. Select the "Debugger" tab in the dialog which appears.
  3. Select "Exceptions" from the popup menu.
  4. Remove the check from the checkbox for java.lang.ArrayIndexOutOfBoundsException.
xerces-2_11_0/docs/faq-common.xml100644 0 0 7753 11474015641 14103 0ustar 0 0 I tried to use &ParserName; to parse an HTML file and it generated an error. What did I do wrong?

Unfortunately, HTML does not, in general, follow the XML grammar rules. Most HTML files do not meet the XML style guidelines. Therefore, the XML parser generates XML well-formedness errors.

Typical errors include:

  • Missing end tags, e.g. <P> with no </P> (end tags are not required in HTML)
  • Missing closing slash on <IMG HREF="foo" /> (not required in HTML)
  • Missing quotes on attribute values, e.g. <IMG width="600"> (not generally required in HTML)

HTML must match the XHTML standard for well-formedness before it can be parsed by &ParserName; or any other XML parser. You can find the XHTML standard on the W3C web site.

I get an "invalid UTF-8 character" error.

There are many Unicode characters that are not allowed in an XML document, according to the XML spec. Typical disallowed characters are control characters, even if you escape them using the Character Reference form: &#xxxx; . See the XML 1.0 specification, sections 2.2 and 4.1 for details. If the parser is generating this error, it is very likely that there is a character in the file that you can not see. You can generally use a UNIX command like "od -hc" to find it.

I get an error when I access EBCDIC XML files, what is happening?

If an XML document/file is not UTF-8, then you MUST specify the encoding. When transcoding a UTF8 document to EBCDIC, remember to change this:

  • <?xml version="1.0" encoding="UTF-8"?>
    to something like this:
    <?xml version="1.0" encoding="ebcdic-cp-us"?>
I get an error on the EOF character (0x1A) -- what is happening?

You are probably using the LPEX editor, which automatically inserts an End-of-file character (0x1A) at the end of your XML document (other editors might do this as well). Unfortunately, the EOF character (0x1A) is an illegal character according to the XML specification, and &ParserName; correctly generates an error.

xerces-2_11_0/docs/faq-contributing.xml100644 0 0 16253 11474015642 15336 0ustar 0 0 I have a problem and I think I know how to fix it. How can I communicate my ideas to the Xerces team?

To maximize the probability that your ideas will grab the attention of one of the Xerces developers who knows about the area of the parser you're concerned with, you should follow these steps:

  1. Check out and build the most recent Xerces code. For instructions on how to do this, see the Source Repository page. If you do this, you can confirm that your bug still exists and has not been fixed since the last release.
  2. Write up your bug report. Include a description of your system (JDK level and vendor, platform and classpath contents) as well as sufficient code to reproduce the problem. This code might involve XML documents, accompanying grammars, and the code you are using to invoke the parser or use its APIs.
  3. Describe why your solution works.
  4. Prepare a patch to fix Xerces code. To do this, when you have applied your changes to a local copy of the most recent xerces source code, do svn diff file for each file you've changed.
  5. Zip (or tar) up your patches. If you send them in the body of a message or bug report they are very difficult to apply.
  6. Submit a bug report on JIRA (remembering to attach your patches and test code) or, if you think your patch might need some discussion, post it to the j-dev@xerces.apache.org list.
I am a recent committer. It has fallen to my lot to prepare a Xerces-J release; how do I do this?

You're in luck--it isn't at all difficult. Just follow these steps and you'll be done in no time:

  1. Ensure that the API code has been properly refreshed. That is, make sure that tools/xml-apis.jar and tools/xml-apis--src.zip reflect the state of the branch of xml-commons that contains the API set to which the parser must conform. At the time of writing (September 2, 2007) this was the main trunk.
  2. Change the following files:
    build.xml (that is, change the parser.Version, parser.version, and parser_version properties as appropriate for the release).
    docs/releases.xml (contributors should have updated this file as significant changes/patches were applied, but the release manager should verify that nothing has slipped through. Also, the release manager should attempt to ensure that appropriate credit has been given for contributions).
  3. Tag the release in SVN (tags for releases usually have the form Xerces-J_x_y_z where x.y.z is the Xerces-J release number) You should also tag the current branch of xml-commons containing the APIs that the parser needs to conform to; see step 1 above.
  4. Do a test build and regression test run; i.e., build test at a bare minimum. In general, apply as many test suites (OASIS XML tests, W3C DOM and Schema tests etc.) as are available, particularly with a view to preventing regressions since the previous release.
  5. Do the final build based on that tag:
    windows build to produce .zip packages
    unix build (on a unix machine to make sure no 0x0d's appear in documentation of .tar.gz packages. Beware to do the build from within X-windows to avoid problems with StyleBook on the command-line!
  6. zip and tar the tools directory
  7. Generate PGP/GNUPG signatures for dist binaries:
    That is, add public key to the SVN KEYS file if necessary and make sure public key is on a key server or two.
  8. Upload the binaries and signatures to the dist section of the website
  9. Update /www/xml.apache.org/dist/xerces-j/.htaccess, which directs the user to the most recent release. Take care to move old packages to the old_xerces directory so that the package listing is manageable.
  10. Prepare release e-mail -- be sure to give contributors credit for their work
  11. Send the release e-mail to the xerces-j lists, general@xml.apache.org and, if it's a big enough release, announcements@xml.apache.org and announcements@apache.org
  12. JIRA:
    Firstly, create new release. Then, remove oldest release (if we are up-to 6 releases).
  13. Website:
    Upload generated docs directory to minotaur (until this process matures and becomes SVN-based). Commit /www/xerces.apache.org/xerces2-j to SVN; i.e., update the xml-site module.
xerces-2_11_0/docs/faq-dom.xml100644 0 0 44541 11474015642 13407 0ustar 0 0 Is Xerces DOM implementation thread-safe?

No. DOM does not require implementations to be thread safe. If you need to access the DOM from multiple threads, you are required to add the appropriate locks to your application code.

How do I create a DOM parser?

You can create a DOM parser by using the Java APIs for XML Processing (JAXP) or using the DOM Level 3 Load and Save.

The following source code shows how to create the parser with JAXP:

import java.io.IOException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.FactoryConfigurationError; import javax.xml.parsers.ParserConfigurationException; import org.w3c.dom.Document; import org.xml.sax.SAXException; ... String xmlFile = "file:///&parserdir;/data/personal.xml"; try { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder builder = factory.newDocumentBuilder(); Document document = builder.parse(xmlFile); } catch (FactoryConfigurationError e) { // unable to get a document builder factory } catch (ParserConfigurationException e) { // parser was unable to be configured catch (SAXException e) { // parsing error } catch (IOException e) { // i/o error }

The following source code shows how to create the parser using DOM Level 3:

import org.w3c.dom.bootstrap.DOMImplementationRegistry; import org.w3c.dom.Document; import org.w3c.dom.ls.DOMImplementationLS; import org.w3c.dom.ls.LSParser; ... DOMImplementationRegistry registry = DOMImplementationRegistry.newInstance(); DOMImplementationLS impl = (DOMImplementationLS)registry.getDOMImplementation("LS"); LSParser builder = impl.createLSParser( DOMImplementationLS.MODE_SYNCHRONOUS, null); Document document = builder.parseURI("data/personal.xml"); You can now use DOM Level 3 Load/Save and Core interfaces with the regular Xerces distribution. How do I serialize DOM to an output stream?

You can serialize a DOM tree by using the DOM Level 3 Load and Save. LSSerializer performs automatic namespace fixup to make your document namespace well-formed.

import org.w3c.dom.bootstrap.DOMImplementationRegistry; import org.w3c.dom.Document; import org.w3c.dom.ls.DOMImplementationLS; import org.w3c.dom.ls.LSSerializer; ... DOMImplementationRegistry registry = DOMImplementationRegistry.newInstance(); DOMImplementationLS impl = (DOMImplementationLS)registry.getDOMImplementation("LS"); ... LSSerializer writer = impl.createLSSerializer(); String str = writer.writeToString(document);

You can also serialize a DOM tree by using the JAXP Transformer API.

It is also possible to serialize a DOM tree by using the Xerces org.apache.xml.XMLSerializer serialization code directly. This non-standard way of serializing a DOM has been deprecated since Xerces-J 2.9.0 and should be avoided if possible.

import org.apache.xml.serialize.OutputFormat; import org.apache.xml.serialize.XMLSerializer; import org.apache.xml.serialize.LineSeparator; ... OutputFormat format = new OutputFormat((Document)core); format.setLineSeparator(LineSeparator.Windows); format.setIndenting(true); format.setLineWidth(0); format.setPreserveSpace(true); XMLSerializer serializer = new XMLSerializer ( new FileOutputStream("output.xml"), format); serializer.asDOMSerializer(); serializer.serialize(document); Does Xerces DOM implement java.io.Serializable?

Yes. Xerces DOM can be serialized using Java object serialization. It is recommended that a DOM be serialized as XML where possible instead of using object serialization.

By choosing object serialization you sacrifice interoperability between parsers and we do not guarantee interoperability between versions of Xerces. It should be used with caution.

Some rough measurements have shown that XML serialization performs better than Java object serialization and that XML instance documents require less storage space than object serialized DOMs.

How do I supply my own implementation of the DOM?

Use the http://apache.org/xml/properties/dom/document-class-name property to register your own implementation of the org.w3c.dom.Document interface.

Xerces provides the following implementations of the org.w3c.dom.Document interface:

  • org.apache.xerces.dom.CoreDocumentImpl -- supports DOM Level 3 Core Recommendation.
  • org.apache.xerces.dom.DocumentImpl -- supports DOM Level 3 Core, Mutation Events, Traversal and Ranges.
  • org.apache.xerces.dom.PSVIDocumentImpl -- provides access to the post schema validation infoset via DOM.
 How do I access the DOM Level 3 functionality?

The DOM Level 3 functionality is now exposed by default since Xerces-J 2.7.0.

The experimental interfaces which were once present in the org.apache.xerces.dom3 package no longer exist. This package existed primarily so that the DOM Level 2 and DOM Level 3 implementations in Xerces-J 2.6.2 and prior could co-exist. Code which depended on the org.apache.xerces.dom3 package must be modified to use the official DOM Level 3 API located in the org.w3c.dom.* packages.

For more information, refer to the DOM Level 3 Implementation page.

How do I run DOM Level 3 applications under JDK 1.4 and higher?

Use the Endorsed Standards Override Mechanism to specify xercesImpl.jar and xml-apis.jar. A more complete description is available here.

How do I retrieve PSVI from the DOM?

By default Xerces does not store the PSVI information in the DOM tree.

The following source shows you how to parse an XML document (using JAXP) and how to retrieve PSVI (using the XML Schema API): //dbf is JAXP DocumentBuilderFactory // all of the following features must be set: dbf.setNamespaceAware(true); dbf.setValidating(true); dbf.setAttribute("http://apache.org/xml/features/validation/schema", Boolean.TRUE); // you also must specify Xerces PSVI DOM implementation // "org.apache.xerces.dom.PSVIDocumentImpl" dbf.setAttribute("http://apache.org/xml/properties/dom/document-class-name", "org.apache.xerces.dom.PSVIDocumentImpl"); ... Document doc = db.parse(args[0]); if (doc.getDocumentElement().isSupported("psvi", "1.0")){ ElementPSVI psviElem = (ElementPSVI)doc.getDocumentElement(); XSElementDeclaration decl = psviElem.getElementDeclaration(); ... }

If you want to build the DOM tree in memory and be able to access the PSVI information you need to start by instantiating org.apache.xerces.dom.PSVIDocumentImpl or you need to use the DOM Level 3 API as shown in the following example:

System.setProperty(DOMImplementationRegistry.PROPERTY, "org.apache.xerces.dom.DOMXSImplementationSourceImpl"); DOMImplementationRegistry registry = DOMImplementationRegistry.newInstance(); DOMImplementation impl = (DOMImplementation) registry.getDOMImplementation("psvi"); The PSVI information will not be added or modified as you modify the tree in memory. Instead, if you want to get updated PSVI information, you need to validate your DOM in memory using the normalizeDocument method as described in the next question.

You can find more information about how to use the XML Schema API here.

 How can I make sure that my DOM document in memory conforms to a schema?

DOM revalidation is supported via W3C DOM Level 3 Core Document.normalizeDocument().

This release only supports revalidation against XML Schemas and DTDs. Revalidation against other schema types is not implemented.

To revalidate the document you need:

  • Create the DOMParser.
  • Retrieve DOMConfiguration from the Document, and set validate feature to true.
  • Provide XML Schemas (agains which validation should occur) by either setting xsi:schemaLocation / xsi:noSchemaLocation attributes on the documentElement, or by setting schema-location parameter on the DOMConfiguration.
  • Relative URIs for the schema documents will be resolved relative to the documentURI (which should be set). Otherwise, you can implement your own LSResourceResolver and set it via resource-resolver on the DOMConfiguration.

Note: if a document contains any DOM Level 1 nodes (the nodes created using createElement, createAttribute, etc.) a fatal error will occur as described in the Namespace Normalization algorithm. In general, the DOM specification discourages using DOM Level 1 nodes in the namespace aware application:

DOM Level 1 methods are namespace ignorant. Therefore, while it is safe to use these methods when not dealing with namespaces, using them and the new ones at the same time should be avoided. DOM Level 1 methods solely identify attribute nodes by their nodeName. On the contrary, the DOM Level 2 methods related to namespaces, identify attribute nodes by their namespaceURI and localName. Because of this fundamental difference, mixing both sets of methods can lead to unpredictable results.

import org.w3c.dom.Document; import org.w3c.dom.DOMConfiguration; import org.w3c.dom.ls.LSParser; ..... Document document = builder.parseURI("data/personal-schema.xml"); DOMConfiguration config = document.getDomConfig(); config.setParameter("error-handler",new MyErrorHandler()); config.setParameter("schema-type", "http://www.w3.org/2001/XMLSchema"); config.setParameter("validate", Boolean.TRUE); document.normalizeDocument();

For more information, please refer to the DOM Level 3 Implementation page.

How do I handle errors?

You should register an error handler with the parser by supplying a class which implements the org.xml.sax.ErrorHandler interface. This is true regardless of whether your parser is a DOM based or SAX based parser.

You can register an error handler on a DocumentBuilder created using JAXP like this:

import javax.xml.parsers.DocumentBuilder; import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; ErrorHandler handler = new ErrorHandler() { public void warning(SAXParseException e) throws SAXException { System.err.println("[warning] "+e.getMessage()); } public void error(SAXParseException e) throws SAXException { System.err.println("[error] "+e.getMessage()); } public void fatalError(SAXParseException e) throws SAXException { System.err.println("[fatal error] "+e.getMessage()); throw e; } }; DocumentBuilder builder = /* builder instance */; builder.setErrorHandler(handler);

If you are using DOM Level 3 you can register an error handler with the LSParser by supplying a class which implements the org.w3c.dom.DOMErrorHandler interface. Note: all exceptions during parsing or saving XML data are reported via DOMErrorHandler.

 How can I control the way that entities are represented in the DOM?

The Xerces http://apache.org/xml/features/dom/create-entity-ref-nodes feature (or corresponding DOM Level 3 LSParser entities feature) controls how entities appear in the DOM tree. When one of those features is set to true (the default), an occurrence of an entity reference in the XML document will be represented by a subtree with an EntityReference node at the root whose children represent the entity expansion.

If the feature is false, an entity reference in the XML document is represented by only the nodes that represent the entity expansion.

In either case, the entity expansion will be a DOM tree representing the structure of the entity expansion, not a text node containing the entity expansion as text.

How do I associate my own data with a node in the DOM tree?

The class org.apache.xerces.dom.NodeImpl provides the setUserData(Object o) and the Object getUserData() methods that you can use to attach any object to a node in the DOM tree.

Beware that you should try and remove references to your data on nodes you no longer use (by calling setUserData(null), or these nodes will not be garbage collected until the entire document is garbage collected.

If you are using Xerces with the DOM Level 3 support you can use org.w3c.dom.Node.setUserData() and register your own UserDataHandler.

Why does getElementById not work for documents validated against XML Schemas?

Make sure the validation feature and the schema feature are turned on before you parse a document.

How do I specify an ID attribute in the DOM?

You can use the DOM level 3 setIdAttribute, setIdAttributeNS, and setIdAttributeNode methods to specify ID attribute in the DOM. See DOM Level 3.

How do I access type information in the DOM?

DOM Level 3 defines a TypeInfo interface that exposes type information for element and attribute nodes. The type information depends on the document schema and is only available if Xerces was able to find the corresponding grammar (DOM Level 3 validate or validate-if-schema feature must be turned on). If you need to access the full PSVI in the DOM please refer to Using XML Schemas.

xerces-2_11_0/docs/faq-general.xml100644 0 0 32360 11474015642 14241 0ustar 0 0 How do I find out which Xerces version I am using?

To find out the release version of Xerces, execute the following: java org.apache.xerces.impl.Version.

How do I use JIRA to report bugs?

Please refer to the Reporting bugs in JIRA.

What happened to xerces.jar?

In order to take advantage of the fact that this parser is very often used in conjunction with other XML technologies, such as XSLT processors, which also rely on standard API's like DOM and SAX, xerces.jar was split into two jarfiles:

  • xml-apis.jar contains the DOM level 3, SAX 2.0.2 and the JAXP 1.4 APIs;
  • xercesImpl.jar contains the implementation of these API's as well as the XNI API.

For backwards compatibility, we have retained the ability to generate xerces.jar. For instructions, see the installation documentation.

How can I use JAXP 1.4 on JDK 1.4 and above?

Use the Endorsed Standards Override Mechanism to specify xml-apis.jar and xercesImpl.jar. This will override the version of JAXP in the JDK. A more complete description is available here.

The following methods do not work:

  • Using the CLASSPATH environment variable or using -classpath to place the new classes in the classpath.
  • Using the -jar option to explicitly execute the classes inside the new jar files.

 Why do I get a ClassCastException when I use Xerces and WebSphere Application Server?

Xerces uses the ObjectFactory class to load some classes dynamically, e.g. the parser configuration. The ObjectFactory finds the specified implementation class by querying the system property, reading META-INF/services/factoryId file or using a fallback classname. After the implementation is found, the ObjectFactory tries to load the file using the context classloader and if it is null, the ObjectFactory uses the system classloader.

If you run Xerces in an environment, such as WebSphere® Application Server, that has multiple classloaders you may get ClassCastExceptions thrown from Xerces because different classloaders might get involved in loading Xerces classes. For example, ClassCastExceptions may occur when utility EAR classes that use Xerces load Xerces classes from WAR modules.

We suggest you read the "Avoiding ClassCastExceptions..." article which explains a workaround for this problem. Also you might want to read the "J2EE Class Loading Demystified" article that explains how multiple classloaders work in WebSphere Application Server.

What should I be using instead of Xerces' XML, HTML or XHTML serializers?

As of the 2.9.0 release Xerces-J began sharing a common serialization codebase with Xalan and now includes serializer.jar with its distribution for DOM Level 3 serialization support. The entire org.apache.xml.serialize package was deprecated in Xerces 2.9.0. The HTML and XHTML serializers were previously deprecated in the Xerces 2.6.2 release. You can find more details about the rationale for this decision here in the archives.

If you want to achieve interoperability and avoid using deprecated APIs, you should not be using Xerces serialization code directly. Instead, the JAXP Transformer API should be used to serialize HTML, XHTML, and SAX. The DOM Level 3 Load and Save API (or JAXP Transformer API) should be used to serialize DOM.

Using DOM Level 3 you can serialize XML as follows:

import org.w3c.dom.bootstrap.DOMImplementationRegistry; import org.w3c.dom.Document; import org.w3c.dom.ls.DOMImplementationLS; import org.w3c.dom.ls.LSSerializer; import org.w3c.dom.ls.LSOutput; ... DOMImplementationRegistry registry = DOMImplementationRegistry.newInstance(); DOMImplementationLS impl = (DOMImplementationLS)registry.getDOMImplementation("LS"); ... LSSerializer writer = impl.createLSSerializer(); LSOutput output = impl.createLSOutput(); output.setByteStream(System.out); writer.write(document, output);

Using JAXP you can serialize HTML and XHTML as follows:

// Create an "identity" transformer - copies input to output Transformer t = TransformerFactory.newInstance().newTransformer(); // for "XHTML" serialization, use the output method "xml" // and set publicId as shown t.setOutputProperty(OutputKeys.METHOD, "xml"); t.setOutputProperty(OutputKeys.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Transitional//EN"); t.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"); // For "HTML" serialization, use t.setOutputProperty(OutputKeys.METHOD, "html"); // Serialize DOM tree t.transform(new DOMSource(doc), new StreamResult(System.out)); I don't need all the features Xerces provides, but I'm running in an environment where space is at a premium. Is there anything I can do?

Partially to address this issue, we've recently begun to distribute compressed jar files instead of our traditionally uncompressed files. But if you still need a smaller jar, and don't need things like support for XML Schema or the WML/HTML DOM implementations that Xerces provides, then look at the dtdjars target in our buildfile.

How do I turn on DTD validation?

You can turn validation on and off via methods available on the SAX2 XMLReader interface. While only the SAXParser implements the XMLReader interface, the methods required for turning on validation are available to both parser classes, DOM and SAX.
The code snippet below shows how to turn validation on -- assume that parser is an instance of either org.apache.xerces.parsers.SAXParser or org.apache.xerces.parsers.DOMParser.

parser.setFeature("http://xml.org/sax/features/validation", true);

What international encodings are supported by &ParserName;?
  • UTF-8
  • UTF-16 Big Endian and Little Endian
  • UCS-2 (ISO-10646-UCS-2) Big Endian and Little Endian
  • UCS-4 (ISO-10646-UCS-4) Big Endian and Little Endian
  • IBM-1208
  • ISO Latin-1 (ISO-8859-1)
  • ISO Latin-2 (ISO-8859-2) [Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (in Latin transcription), Serbocroatian, Slovak, Slovenian, Upper and Lower Sorbian]
  • ISO Latin-3 (ISO-8859-3) [Maltese, Esperanto]
  • ISO Latin-4 (ISO-8859-4)
  • ISO Latin Cyrillic (ISO-8859-5)
  • ISO Latin Arabic (ISO-8859-6)
  • ISO Latin Greek (ISO-8859-7)
  • ISO Latin Hebrew (ISO-8859-8)
  • ISO Latin-5 (ISO-8859-9) [Turkish]
  • ISO Latin-7 (ISO-8859-13)
  • ISO Latin-9 (ISO-8859-15)
  • Extended Unix Code, packed for Japanese (euc-jp, eucjis)
  • Japanese Shift JIS (shift-jis)
  • Chinese (big5)
  • Chinese for PRC (mixed 1/2 byte) (gb2312)
  • Japanese ISO-2022-JP (iso-2022-jp)
  • Cyrillic (koi8-r)
  • Extended Unix Code, packed for Korean (euc-kr)
  • Russian Unix, Cyrillic (koi8-r)
  • Windows Thai (cp874)
  • Latin 1 Windows (cp1252) (and all other cp125? encodings recognized by IANA)
  • cp858
  • EBCDIC encodings:
    • EBCDIC US (ebcdic-cp-us)
    • EBCDIC Canada (ebcdic-cp-ca)
    • EBCDIC Netherland (ebcdic-cp-nl)
    • EBCDIC Denmark (ebcdic-cp-dk)
    • EBCDIC Norway (ebcdic-cp-no)
    • EBCDIC Finland (ebcdic-cp-fi)
    • EBCDIC Sweden (ebcdic-cp-se)
    • EBCDIC Italy (ebcdic-cp-it)
    • EBCDIC Spain, Latin America (ebcdic-cp-es)
    • EBCDIC Great Britain (ebcdic-cp-gb)
    • EBCDIC France (ebcdic-cp-fr)
    • EBCDIC Hebrew (ebcdic-cp-he)
    • EBCDIC Switzerland (ebcdic-cp-ch)
    • EBCDIC Roece (ebcdic-cp-roece)
    • EBCDIC Yugoslavia (ebcdic-cp-yu)
    • EBCDIC Iceland (ebcdic-cp-is)
    • EBCDIC Urdu (ebcdic-cp-ar2)
    • Latin 0 EBCDIC
    • EBCDIC Arabic (ebcdic-cp-ar1)
 Why is the parser unable to access schema documents or external entities available on the Internet?

The parser may not be able to access various external entities or schema documents (imported, included etc...) available on the Internet, such as the Schema for Schemas "http://www.w3.org/2001/XMLSchema.xsd" or the schema defining xml:base, xml:lang attributes etc... "http://www.w3.org/2001/xml.xsd" or any other external entity available on the Internet. There are various reasons one could experience such a problem.

One of the reasons could be that your proxy settings do not allow the parser to make URL connections through a proxy server. To solve this problem, before parsing a document, the application must set the two system properties: "http.proxyHost" and "http.proxyPort". Another reason could be due to strict firewall settings that do not allow any URL connection to be made to the outside web. The problem may also be caused by a server that is offline or inaccessible on the network, preventing documents hosted by the server from being accessed.

What JDK level is required for Xerces?

As of version 2.10.0, Xerces requires JDK 1.3 or later to run and also requires JDK 1.3 or later to build the source code. Starting with the Xerces 2.11.0 release, the XML Schema 1.1 experimental distribution requires JDK 1.4 or later to run and also to build the source code.

xerces-2_11_0/docs/faq-grammars.xml100644 0 0 46210 11474015642 14434 0ustar 0 0 I have a set of (DTD or XML Schema) grammars that I use a lot. How can I make Xerces reuse the representations it builds for these grammars, instead of parsing them anew with every new document?

Before answering this question, it will greatly help to understand how Xerces handles grammars internally. To do this, here are some terms:

  • Grammar: defined in the org.apache.xerces.xni.grammars.Grammar interface; simply differentiates objects that are Xerces grammars from other objects, as well as providing a means to get at the location information (XMLGrammarDescription) for the grammar represented..
  • XMLGrammarDescription: defined by the org.apache.xerces.xni.grammars.XMLGrammarDescription interface, holds some basic location information common to all grammars. This can be used to distinguish one Grammar object from another, and also contains information about the type of the grammar.
  • Validator: A generic term used in Xerces to denote an object which compares the structure of an XML document with the expectations of a certain type of grammar. Currently, we have DTD and XML Schema validators.
  • XMLGrammarPool: Defined by the org.apache.xerces.xni.grammars.XMLGrammarPool interface, this object is owned by the application and it is the means by which the application and Xerces pass complex grammars to one another.
  • Grammar bucket: An internal data structure owned by a Xerces validator in which grammars--and information related to grammars--to be used in a given validation episode is stored.
  • XMLGrammarLoader: defined in the org.apache.xerces.xni.grammars.XMLGrammarLoader interface, this defines an object that "knows how" to read the XML representation of a particular kind of grammar and construct a Xerces-internal representation (a Grammar object) out of it. These objects may interact with validators during parsing of instance documents, or with external code during grammar preparsing.

Now that the terminology is out of the way, it's possible to relate all these objects together. At the commencement of a validation episode, a validator will call the retrieveInitialGrammarSet(String grammarType) method of the XMLGrammarPool instance to which it has access. It will use the Grammar objects it procures in this way to seed its grammar bucket.

When the validator determines that it needs a grammar, it will consult its grammar bucket. If it finds a matching grammar, it will attempt to use it. Otherwise, if it has access to an XMLGrammarPool instance, it will request a grammar from that object with the retrieveGrammar(XMLGrammarDescription desc) method. Only if both of these steps fail will it fall back to attempting to resolve the grammar entity and calling the appropriate XMLGrammarLoader to actually create a new Grammar object.

At the end of the validation episode, the validator will call the cacheGrammars(String grammarType, Grammar[] grammars) method of the XMLGrammarPool (if any) to which it has access. There is no guarantee grammars that the grammar pool itself supplied to the validator will not be included in this set, so a grammar pool implementation cannot rely only on new grammars to be passed back in this situation.

At long last, it's now possible to answer the original question--how can one cache grammars? Assuming one has a reasonable XMLGrammarPool implementation--such as that provided with Xerces--there are two answers:

  1. The "passive" approach: Don't do any preparsing, just register the grammar pool implementation with the parser, and as new grammars are requested by instance documents, simply let the validators add them to the pool. This is very unobtrusive to the application, but doesn't provide that much control over what grammars are added; even if a custom EntityResolver is registered, it's still possible that unwanted grammars will make it into the pool.
  2. The "active" approach: Preload a grammar pool implementation with all the grammars you'll need, then lock it so that no new grammars will be added. Then registering this on the configuration will allow validators to make use of this set; registering a do-nothing EntityResolver will allow the application to deny validators from using any but the "approved" grammar set. This will oblige the application to use more Xerces code, but provides a far more fine-grained approach to controlling what grammars may be used.

We discuss both these approaches in a bit more detail below, complete with some (broad) examples. As a starting point, though, the XMLGrammarBuilder sample, from the xni package, should provide a starting-point for implementing either the active or passive approach.

Exactly how does Xerces default implementation of things like the grammar pool work?

Before proceeding further, let there be no doubt that, by default, Xerces does not cache grammars at all. In order to trigger Xerces grammar caching, an XMLGrammarPool must be set, using the setProperty method, on a Xerces configuration that supports grammar pools. On the other hand, you could simply use the XMLGrammarCachingConfiguration as discussed briefly below.

When enabled, by default, Xerces's grammar pool implementation stores any grammar offered to it (provided it does not already have a reference matching that grammar). It also makes available all grammars it has, of a particular type, on calls to retrieveInitialGrammarSet. It will also try and retrieve a matching grammar on calls to retrieveGrammar.

Xerces uses hashing to distinguish different grammar objects, by hashing on the XMLGrammarDescription objects that those grammars contain. Thus, both of Xerces implementations of XMLGrammarDescription--for DTD's and XML Schemas--provide implementations of hashCode(): int and equals(Object):boolean that are used by the hashing algorithm.

In XML Schemas, hashing is simply carried out on the target namespace of the schema. Thus, two grammars are considered equal (by our default implementation) if and only if their XMLGrammarDescriptions are instances of org.apache.xerces.impl.xs.XSDDescription (our schema implementation of XMLGrammarDescription) and the targetNamespace fields of those objects are identical.

The case in DTD's is much more difficult. Here is the algorithm, which describes the conditions under which two DTD grammars will be considered equal:

  • Both grammars must have XMLGrammarDescriptions that are instances of org.apache.xerces.impl.dtd.XMLDTDDescription.
  • If their publicId or expandedSystemId fields are non-null they must be identical;
  • If one of the descriptions has a root element defined, it must be the same as the root element defined in the other description, or be in the list of global elements stored in that description;
  • If neither has a root element defined, then they must share at least one global element declaration in common.

The DTD grammar caching also assumes that the entirety of the cached grammar will lie in an external subset. i.e., in the example below, Xerces will happily cache--or use a cached version of--the DTD in "my.dtd". If the document contained an internal subset, the declarations would be ignored.

<!DOCTYPE myDoc SYSTEM "my.dtd"> <myDoc ...>...</myDoc>

Using these heuristics, Xerces's default grammar caching implementation appears to do a reasonable job at matching grammars up with appropriate instance documents. This functionality is very new, so in addition to bug reports we'd very much appreciate, especially on the DTD front, feedback on whether this form of caching is indeed useful or whether--for instance--it would be better if internal declarations were somehow incorporated into the grammar that's been cached.

I like the idea of "active" caching (or I want the grammar object for some purpose); how do I go about parsing a grammar independent of an instance document?

First, if you haven't read the first FAQ on this page and have trouble with terminology, hopefully answers lie there.

Preparsing of grammars in Xerces is accomplished with implementations of the XMLGrammarLoader interface. Each implementation needs to know how to parse a particular type of grammar and how to build a data structure representing that grammar that Xerces can efficiently make use of in validation. Since most application programs won't want to deal with Xerces implementations per se, we have provided a handy utility class to handle grammar preparsing generally: org.apache.xerces.parsers.XMLGrammarPreparser. This FAQ describes the use of this class. For a live example, check out the XMLGrammarBuilder sample in the samples/xni directory of the binary distribution.

XMLGrammarPreparser has methods for installing XNI error handlers, entity resolvers, setting the Locale, and generally doing similar things as an XNI configuration. Any object passed to XMLGrammarPreparser by any of these methods will be passed on to all XMLGrammarLoaders registered with XMLGrammarPreparser.

Before XMLGrammarPreparser can be used, its registerPreparser(String, XMLGrammarLoader): boolean method must be called. This allows a String identifying an arbitrary grammar type to be associated with a loader for that type. To make peoples' lives easier, if you want DTD grammars or XML Schema grammar support, you can pass null for the second parameter and XMLGrammarPreparser will try and instantiate the appropriate default grammar loader. For DTD's, for instance, just call registerPreparser like:

grammarPreparser("http://www.w3.org/TR/REC-xml", null)

Schema grammars correspond to the URI "http://www.w3.org/2001/XMLSchema"; both these constants can be found in the org.apache.xerces.xni.grammars.XMLGrammarDescription interface. The method returns true if an XMLGrammarLoader was successfully associated with the given grammar String, false otherwise.

XMLGrammarPreparser also contains methods for setting features and properties on particular loaders--keyed on with the same string that was used to register the loader. It also allows features and properties the application believes to be general to all loaders to be set; it transmits such features and properties to each loader that is registered. These methods also silently consume any notRecognized/notSupported exceptions that the loaders throw. Particularly useful here is registering an XMLGrammarPool implementation, such as that found in org.apache.xerces.util.XMLGrammarPoolImpl.

To actually parse a grammar, one simply calls the preparseGrammar(String grammarType, XMLInputSource source): Grammar method. As above, the String represents the type of the grammar to be parsed, and the XMLInputSource is the location of the grammar to be parsed; this will not be subjected to entity expansion.

It's worth noting that Xerces default grammar loaders will attempt to cache the resulting grammar(s) if a grammar pool implementation is registered with them. This is particularly useful in the case of schema grammars: If a schema grammar imports another grammar, the Grammar object returned will be the schema doing the importing, not the one being imported. For caching, this means that if this grammar is cached by itself, the grammars that it imports won't be available to the grammar pool implementation. Since our Schema Loader knows about this idiosyncrasy, if a grammar pool is registered with it, it will cache all schema grammars it encounters, including the one which it was specifically called to parse. In general, it is probably advisable to register grammar pool implementations with grammar loaders for this reason; generally, one would want to cache--and make available to the grammar pool implementation--imported grammars as well as specific schema grammars, since the specific schemas cannot be used without those that they import.

All right, I've (somehow) got a grammar pool full of grammars. How do I use this with my application that uses standard (SAX|DOM|JAXP) parsers?

For SAX and DOM the case is simple. Just do:

XMLParserConfiguration config = new &DefaultConfig;(); config.setProperty("http://apache.org/xml/properties/internal/grammar-pool", myFullGrammarPool); (SAX|DOM)Parser parser = new (SAX|DOM)Parser(config);

Now your grammar pool instance will be used by all validators created by this parser to validate your instance documents.

If you have an application that uses pure JAXP, your task is a bit trickier. You'll need to do something like this:

System.setProperty("org.apache.xerces.xni.parser.XMLParserConfiguration", "org.apache.xerces.parsers.XMLGrammarCachingConfiguration"); DocumentBuilder builder = // JAXP factory invocation // parse documents and store grammars

Note that this only supports the "passive" caching approach discussed in above. The org.apache.xerces.parsers.XMLGrammarCachingConfiguration represents experimental code; feedback on whether it is useful would be greatly appreciated.

But I don't want to "preparse" grammars for efficiency; I want to parse them in order to look at their contents using some API! Can I do this?

Yes, for grammar types for which such an API is defined. No such API exists at the current moment for DTD's. For XML Schemas, Xerces implements the XML Schema API. For details, it's best to look at the API docs for the org.apache.xerces.xs package. Assuming you have produced a Grammar object from an XML Schema document by some means, to turn that object into an object usable in this API, do the following:

  1. Cast the Grammar object to org.apache.xerces.xni.grammars.XSGrammar;
  2. Call the toXSModel() method on the casted object;
  3. Use the methods in the org.apache.xerces.xs.XSModel interface to examine the new object; methods on this interface and others in the same package should allow you to access all aspects of the schema.
Is there an alternative method for getting an XSModel?

Yes, for more information see the XML Schema FAQ.

xerces-2_11_0/docs/faq-pcfp.xml100644 0 0 16333 11474015642 13556 0ustar 0 0 What's the result of having a DTD validator or XML Schema validator in the pipeline?

If a validator is included in the pipeline, the assessment is done, whether the validation feature is set to true or false. The validation feature only enables the validation constraint error reporting and it does not control the infoset augmentation: if a validator is included in the pipeline the parser will augment the infoset according to the grammar specified for the instance document.

What validation behavior do I expect from the default parser configuration?

The default configuration (&DefaultConfigLong;) includes the DTD validator and the document scanner (which are both capable of namespace binding). Thus, the validation feature will enable validation against a DTD only. To allow validation against XML Schemas you must turn on the validation feature and the schema feature, and XML Schema Validator will be inserted in the pipeline. if you've created your own configuration which does not extend &DefaultConfig; (or another suitable configuration included with the parser), you must make sure that your configuration inserts all needed validators in the pipeline.

What happens if I set both validation and schema validation features on?

If both validators are present in the pipeline (this is the default behavior), then

  • if the instance document has only a DTD grammar (DOCTYPE before the root element), then only DTD validation errors are reported;
  • if the instance document has only XML Schema grammars, then only XML Schema validation errors are reported
  • if the instance document has both DTD and XML Schema grammars, validation errors for both DTD and XML Schema are reported;
  • if no grammar can be found for the instance document, the last validator in the pipeline will report validation errors.

An application may choose to create a configuration that does not have a DTD validator but has an XML Schema validator. This will turn Xerces into a non-compliant processor according to XML 1.0 and XML Schema specifications, thus the validation/augmentation outcome is undefined.

How can I tell the parser to validate against XML Schema and not to report DTD validation errors?

Using JAXP you can instruct the parser to validate against XML Schema only. The JAXP 1.4 Validation API allows you to build an in-memory representation of an XML Schema which you can then set on a parser factory. Parsers created from the factory will validate documents using the schema object you specified.

By doing the following you can configure a SAX parser or DocumentBuilder to validate against XML Schema only:

import javax.xml.XMLConstants; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import javax.xml.transform.stream.StreamSource; import javax.xml.validation.Schema; import javax.xml.validation.SchemaFactory; ... StreamSource[] sources = /* created by your application */; SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); Schema schema = factory.newSchema(sources); /** Setup SAX parser for schema validation. */ SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setNamespaceAware(true); spf.setSchema(schema); SAXParser parser = spf.newSAXParser(); /** Setup DocumentBuilder for schema validation. */ DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); dbf.setSchema(schema); DocumentBuilder db = dbf.newDocumentBuilder(); ...

Changing the value of the schema language parameter passed to SchemaFactory.newInstance() to http://www.w3.org/XML/XMLSchema/v1.1 will create a processor which supports XML Schema 1.1.

import javax.xml.transform.stream.StreamSource; import javax.xml.validation.Schema; import javax.xml.validation.SchemaFactory; ... StreamSource[] sources = /* created by your application */; SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/XML/XMLSchema/v1.1"); Schema schema = factory.newSchema(sources); ...

Another option is to use the JAXP schema language property defined by JAXP 1.2. If the schema language property has been set to http://www.w3.org/2001/XMLSchema and the parser has been configured to validate then your documents will be validated against XML Schema only, even if they have a DTD.

By doing the following you can configure a SAX parser to validate against XML Schema only:

import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; ... SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setValidating(true); spf.setNamespaceAware(true); SAXParser parser = spf.newSAXParser(); parser.setProperty( "http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); ...

For a DocumentBuilder this can be accomplished by doing the following:

import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; ... DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); dbf.setValidating(true); dbf.setAttribute( "http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); DocumentBuilder docBuilder = dbf.newDocumentBuilder(); ... xerces-2_11_0/docs/faq-performance.xml100644 0 0 15407 11474015641 15127 0ustar 0 0 General Performance

Don't use XML where it doesn't make sense. XML is not a panacea. You will not get good performance by transferring and parsing a lot of XML files.

Using XML is memory, CPU, and network intensive.

 Parser Performance

Avoid creating a new parser each time you parse; reuse parser instances. A pool of reusable parser instances might be a good idea if you have multiple threads parsing at the same time.

The parser configuration may affect the performance of the parser. For example, if you are interested in evaluating the parser performance with DTDs you may want to use the DTDConfiguration (Note: you can build Xerces with DTD-only support using dtdjars build target).

Parsing Documents Performance

There are a variety of things that you can do to improve the performance when parsing documents:

  • Convert the document to US ASCII ("US-ASCII") or Unicode ("UTF-8" or "UTF-16") before parsing. Documents written using ASCII are the fastest to parse because each character is guaranteed to be a single byte and map directly to their equivalent Unicode value. For documents that contain Unicode characters beyond the ASCII range, multiple byte sequences must be read and converted for each character. There is a performance penalty for this conversion. The UTF-16 encoding alleviates some of this penalty because each character is specified using two bytes, assuming no surrogate characters. However, using UTF-16 can roughly double the size of the original document which takes longer to parse.
  • Explicitly specify "US-ASCII" encoding if your document is in ASCII format. If no encoding is specified, the XML specification requires the parser to assume UTF-8 which is slower to process.
  • Avoid external entities and external DTDs. The extra file opens and transcoding setup is expensive.
  • Reduce character count; smaller documents are parsed quicker. Replace elements with attributes where it makes sense. Avoid gratuitous use of whitespace because the parser must scan past it.
  • Avoid using too many default attributes. Defaulting attribute values slows down processing.
XML Application Performance

When writing an XML application there are a number of choices you can make that effect performance. Some of the things which will affect the performance of your application are described below.

  • Grammar Caching -- if you do need validation, consider using grammar caching to reduce the cost of validation by allowing the parser to skip grammar loading and assessment. See this FAQ on how to perform grammar caching with Xerces.
  • Validation -- if you don't need validation (and infoset augmentation) of XML documents, don't include validators (DTD or XML Schema) in the pipeline. Including the validator components in the pipeline will result in a performance hit for your application: if a validator component is present in the pipeline, Xerces will try to augment the infoset even if the validation feature is set to false. If you are only interested in validating against DTDs don't include XML Schema validator in the pipeline.
  • DOCTYPE -- if you don't need validation, avoid using a DOCTYPE line in your XML document. The current version of the parser will always read the DTD if the DOCTYPE line is specified even when validation feature is set to false.
  • Deferred DOM -- by default, the DOM feature defer-node-expansion is true, causing DOM nodes to be expanded as the tree is traversed. The performance tests produced by Denis Sosnoski showed that Xerces DOM with deferred node expansion offers poor performance and large memory size for small documents (0K-10K). Thus, for best performance when using Xerces DOM with smaller documents you should disable the deferred node expansion feature. For larger documents (~100K and higher) the deferred DOM offers better performance than non-deferred DOM but uses a large memory size.
  • SAX -- if memory usage using DOM is a concern, SAX should be considered; the SAX parser uses very little memory and notifies the application as parts of the document are parsed.

For more detailed information on best practices for writing XML applications you may want to read the following series of articles:

  1. Write XML documents and develop applications using the SAX and DOM APIs
  2. Reuse parser instances with the Xerces2 SAX and DOM implementations
  3. XNI, Xerces2 features and properties, and caching schemas

These three articles discuss general performance tips in addition to ones specifically pertaining to Xerces2.

xerces-2_11_0/docs/faq-sax.xml100644 0 0 14567 11474015642 13430 0ustar 0 0 How do I create a SAX parser?

You can create a SAX parser by using the Java APIs for XML Processing (JAXP). The following source code shows how:

import java.io.IOException; import javax.xml.parsers.FactoryConfigurationError; import javax.xml.parsers.ParserConfigurationException; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import org.xml.sax.SAXException; import org.xml.sax.helpers.DefaultHandler; ... String xmlFile = "file:///&parserdir;/data/personal.xml"; try { SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); SAXParser parser = factory.newSAXParser(); DefaultHandler handler = /* custom handler class */; parser.parse(xmlFile, handler); } catch (FactoryConfigurationError e) { // unable to get a document builder factory } catch (ParserConfigurationException e) { // parser was unable to be configured catch (SAXException e) { // parsing error } catch (IOException e) { // i/o error } Why does the SAX parser lose some character data or why is the data split into several chunks?

If you read the SAX documentation, you will find that SAX may deliver contiguous text as multiple calls to characters, for reasons having to do with parser efficiency and input buffering. It is the programmer's responsibility to deal with that appropriately, e.g. by accumulating text until the next non-characters event.

Xerces will split calls to characters at the end of an internal buffer, at a new line and also at a few other boundaries. You can never rely on contiguous text to be passed in a single characters callback.

Why doesn't the SAX parser report ignorable whitespace for XML Schemas?

SAX is very clear that ignorableWhitespace is only called for element content whitespace, which is defined in the context of a DTD. The result of schema validation is the Post-Schema-Validation Infoset (PSVI). Schema processors augment the base Infoset by adding new properties to element and attribute information items, but not character information items. Schemas do not change whether a character is element content whitespace.

Why is the Attributes parameter passed to startElement always a reference to the same object?

Outside the scope of startElement, the value of the Attributes parameter is undefined. For each instance of Xerces' SAX parser, there exists only one Attributes instance which is reused for every new set of attributes. Before each startElement callback, the previous values in this object will be overwritten. This is done for performance reasons in order to reduce object creation. To persist a set of attributes beyond startElement the object should be cloned, for instance by using org.xml.sax.helpers.AttributesImpl.

Why does the SAX parser report that xmlns attributes have no namespace?

An erratum for the Namespaces in XML Recommendation put namespace declaration attributes in the namespace "http://www.w3.org/2000/xmlns/". By default, SAX2 (SAX 2.0.2) follows the original Namespaces in XML Recommendation, so conforming parsers must report that these attributes have no namespace. To configure the parser to report a namespace for such attributes, turn on the xmlns-uris feature.

When using Xerces 2.6.2 (or prior) or other parser implementations that do not support this feature, your code must handle this discrepancy when interacting with APIs such as DOM and applications which expect a namespace for xmlns attributes.

Is there any way I can determine what encoding an entity was written in, or what XML version the document conformed to, if I'm using SAX?

Yes. As of SAX 2.0.2 encoding and version information is made available through the org.xml.sax.ext.Locator2 interface. In Xerces, instances of the SAX Locator interface passed to a setDocumentLocator call will also implement the Locator2 interface. You can determine the encoding and XML version of the entity currently being parsed by calling the getEncoding() and getXMLVersion() methods.

xerces-2_11_0/docs/faq-write.xml100644 0 0 26767 11474015642 13774 0ustar 0 0 How do I handle errors?

You should register an error handler with the parser by supplying a class which implements the org.xml.sax.ErrorHandler interface. This is true regardless of whether your parser is a DOM based or SAX based parser.

You can register an error handler on a DocumentBuilder created using JAXP like this:

import javax.xml.parsers.DocumentBuilder; import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; ErrorHandler handler = new ErrorHandler() { public void warning(SAXParseException e) throws SAXException { System.err.println("[warning] "+e.getMessage()); } public void error(SAXParseException e) throws SAXException { System.err.println("[error] "+e.getMessage()); } public void fatalError(SAXParseException e) throws SAXException { System.err.println("[fatal error] "+e.getMessage()); throw e; } }; DocumentBuilder builder = /* builder instance */; builder.setErrorHandler(handler);

If you are using DOM Level 3 you can register an error handler with the DOMBuilder by supplying a class which implements the org.w3c.dom.DOMErrorHandler interface. For more information, refer to FAQ

You can also register an error handler on a SAXParser using JAXP like this:

import javax.xml.parsers.SAXParser; import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; ErrorHandler handler = new ErrorHandler() { public void warning(SAXParseException e) throws SAXException { System.err.println("[warning] "+e.getMessage()); } public void error(SAXParseException e) throws SAXException { System.err.println("[error] "+e.getMessage()); } public void fatalError(SAXParseException e) throws SAXException { System.err.println("[fatal error] "+e.getMessage()); throw e; } }; SAXParser parser = /* parser instance */; parser.getXMLReader().setErrorHandler(handler); Why does "non-validating" not mean "well-formedness checking" only?

Using a "non-validating" parser does not mean that only well-formedness checking is done! There are still many things that the XML specification requires of the parser, including entity substitution, defaulting of attribute values, and attribute normalization.

This table describes what "non-validating" really means for &ParserName; parsers. In this table, "no DTD" means no internal or external DTD subset is present.

non-validating parsers validating parsers
DTD present no DTD DTD present no DTD
DTD is read Yes No Yes Error
entity substitution Yes No Yes Error
defaulting of attributes Yes No Yes Error
attribute normalization Yes No Yes Error
checking against model No No Yes Error
How do I more efficiently parse several documents sharing a common DTD?

By default, the parser does not cache DTD's. The common DTD, since it is specified in each XML document, will be re-parsed once for each document.

However, there are things that you can do to make the process of reading DTD's more efficient:

  • First, have a look at the grammar caching/preparsing FAQ
  • keep your DTD and DTD references local
  • use internal DTD subsets, if possible
  • load files from server to local client before parsing
  • Cache document files into a local client cache. You should do an HTTP header request to check whether the document has changed, before accessing it over the network.
  • Do not reference an external DTD or internal DTD subset at all. In this case, no DTD will be read.
  • Use a custom EntityResolver and keep common DTDs in a memory buffer.
How can I parse documents in a pull-parsing fashion?

Since the pull-parsing API is specific to Xerces, you have to use a Xerces-specific method to create parsers, and parse documents.

First, you need to create a parser configuration that implements the XMLPullParserConfiguration interface. Then you need to create a parser from this configuration. To parse documents, method parse(boolean) should be called.

import &DefaultConfigLong;; import org.apache.xerces.parsers.SAXParser; import org.apache.xerces.xni.parser.XMLInputSource; ... boolean continueParse = true; void pullParse(XMLInputSource input) throws Exception { &DefaultConfig; config = new &DefaultConfig;(); SAXParser parser = new SAXParser(config); config.setInputSource(input); parser.reset(); while (continueParse) { continueParse = continueParse && config.parse(false); } }

In the above example, a SAXParser is used to pull-parse an XMLInputSource. DOMParser can be used in a similar way. A flag continueParse is used to indicate whether to continue parsing the document. The application can stop the parsing by setting this flag to false.

I would like to know more about the kind of entity my XMLEntityResolver's been asked to resolve. How can I go about convincing Xerces to tell me more?

XNI only guarantees that you'll receive an XMLResourceIdentifier object during an XMLEntityResolver#resolveEntity callback. Nonetheless, the xni.grammars package has a number of interfaces which extend XMLResourceIdentifier that can provide considerably more information.

To take advantage of this, you'll first need to see whether the object you've been passed is an instance of the org.apache.xerces.xni.grammars.XMLGrammarDescription interface. This interface contains a method called getGrammarType which can tell you what kind of grammar is involved (for the moment, XML Schema and DTD's are all that's supported). Once you know the type of grammar, you can cast once again to either org.apache.xerces.xni.grammars.XMLDTDDescription or org.apache.xerces.xni.grammars.XMLSchemaDescription which contain a wealth of information specific to these types of grammars. The javadocs for these interfaces should provide sufficient information for you to know what their various methods return.

xerces-2_11_0/docs/faq-xcatalogs.xml100644 0 0 25517 11474015642 14617 0ustar 0 0 How do I use OASIS XML Catalogs with the parser?

In order to use XML Catalogs with Xerces, the Apache XML Commons Resolver: resolver.jar needs to be on your classpath (or accessible in some other way to the ClassLoader). The resolver provides an implementation of OASIS XML Catalogs v1.1 as well as some other catalog formats. The XML Commons Resolver 1.2 is included with the binary distribution of Xerces. For information about interacting directly with the Resolver's API visit the XML Commons site.

As a convenience for users the parser provides a utility class: org.apache.xerces.util.XMLCatalogResolver which encapsulates the XML Commons Resolver exposing methods relevant to resolving XML entities. It implements the (org.apache.xerces.xni.parser.XMLEntityResolver) XNI entity resolver, the (org.xml.sax.EntityResolver) SAX entity resolver and the (org.w3c.dom.ls.LSResourceResolver) DOM resource resolver interfaces. In XMLCatalogResolver the resolveEntity methods only query the catalog for a mapping of the given identifier. These methods may be overrided if other behaviour is required.

To use XMLCatalogResolver as an XNI EntityResolver you need to do something like this:

import org.apache.xerces.util.XMLCatalogResolver; import org.xml.sax.*; ... XMLReader reader; String [] catalogs = {"file:///C:/catalog/cat1.xml", "file:///C:/catalog/cat2.xml"}; ... // Create catalog resolver and set a catalog list. XMLCatalogResolver resolver = new XMLCatalogResolver(); resolver.setPreferPublic(true); resolver.setCatalogList(catalogs); // Set the resolver on the parser. reader.setProperty( "http://apache.org/xml/properties/internal/entity-resolver", resolver); ...

Note that setting an XNI entity resolver on a SAX or DOM parser will replace any type of entity resolver which was previously registered. If some other type of resolver is registered on the parser it will replace any XNI entity resolver previously registered.

In addition to being used as an entity resolver, it is intended that the XMLCatalogResolver may be used standalone to perform catalog resolution outside of a parsing context. It may also be shared between several parsers and the application. See the API documentation for details.

The XMLCatalogResolver class requires the XML Commons Resolver 1.1 or a version compatible with 1.1. How does XMLCatalogResolver resolve XML Schemas?

If an instance of XMLCatalogResolver has been registered on the parser as an entity resolver it will first try to lookup the schema in the catalog by its target namespace if it has one using the catalog's uri entries. If the schema has no target namespace, or the namespace is unavailable or no mapping for the namespace could be found the resolver will then try to locate the schema using any location hints provided. These location hints are interpreted to be system identifiers.

When XMLCatalogResolver is registered as a SAX entity resolver, the target namespace of the schema will not be available.

The example below demonstrates resolution of URI references for the purpose of reading XML Schema documents. It's assumed that all the files are located in the same directory and that the list of catalog entry files consists only of catalog.xml and that an instance of XMLCatalogResolver has been registered on the parser as an XNI entity resolver. The parser has been instructed to parse and validate the instance document example.xml against an XML Schema. No location hints are provided so only the namespace of the schema components is known. When the parser attempts to locate the schema for the namespace "http://apache.org/xml/xcatalog/example" it would first query the catalog catalog.xml to resolve the namespace to the URI for the schema. The resolver would find that the mapping for the namespace URI is example.xsd and then return this to the parser. The parser would then load the schema, enabling it to validate the instance document.

example.xml: <?xml version="1.0"?> <root xmlns="http://apache.org/xml/xcatalog/example"> http://apache.org/xml/anyURI</root> example.xsd: <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://apache.org/xml/xcatalog/example" targetNamespace="http://apache.org/xml/xcatalog/example"> <xs:element name="root" type="xs:anyURI"/> </xs:schema> catalog.xml: <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <uri name="http://apache.org/xml/xcatalog/example" uri="example.xsd"/> </catalog> How does XMLCatalogResolver resolve DTDs and other external entities?

If an instance of XMLCatalogResolver has been registered on the parser as an entity resolver it will try to lookup the DTD or external entity in the catalog using the system identifier and public identifier if one is available.

The example below demonstrates resolution of external identifiers for the purpose of reading external entities. Resolution of external DTD subsets and external parameter entities can be done similarly. It's assumed that all the files are located in the same directory and that the list of catalog entry files consists only of catalog.xml and that an instance of XMLCatalogResolver has been registered on the parser as an entity resolver. When the parser references the entity named text in the instance document example.xml it would query the catalog catalog.xml to resolve the public identifier. Note that the system identifier is in an URN and after "unwrapping" is equivalent to the public identifier. Since there is no mapping in this catalog for the public identifier, catalog.xml would delegate to catalog2.xml since the public id starts with "-//A//". Upon reading catalog2.xml the resolver would find a mapping for "-//A//XML CATALOG IDENTIFIER//EN" and then return the URI example.ent. The parser would then open this resource and then report "Hello world!" as the replacement text for the entity named text.

example.xml: <?xml version="1.0"?> <!DOCTYPE root [ <!ENTITY text PUBLIC "-//A//XML CATALOG IDENTIFIER//EN" "urn:publicid:-:A:XML+CATALOG+IDENTIFIER:EN"> ]> <root>&text;</root> example.ent: Hello world! catalog.xml: <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <delegatePublic publicIdStartString="-//A//" catalog="catalog2.xml"/> </catalog> catalog2.xml: <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <public publicId="-//A//XML CATALOG IDENTIFIER//EN" uri="example.ent"/> </catalog> Does the parser read the 'oasis-xml-catalog' processing instruction?

No, the parser has no built in support for these processing instructions, however the XML Commons Resolver includes a SAX XMLFilter called org.apache.xml.resolver.tools.ResolvingXMLFilter which is able to process them.

Are other catalog formats supported?

Xerces only includes a utility class for OASIS XML Catalogs, however the XML Commons Resolver supports a few other catalog formats including: the plain text format described by OASIS TR 9401 and the XCatalog XML format defined by John Cowan. For more information visit the XML Commons site.

xerces-2_11_0/docs/faq-xinclude.xml100644 0 0 17004 11474015642 14435 0ustar 0 0 How do I enable XInclude processing?

Applications using JAXP 1.3 (and above) can enable XInclude processing by setting XInclude awareness on the parser factory. The following demonstrates how to accomplish this with SAX:

import javax.xml.parsers.SAXParserFactory; SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setNamespaceAware(true); spf.setXIncludeAware(true); ...

You can also enable XInclude processing by turning on the XInclude feature.

How do the validation features interact with XInclude processing?

If the validation feature is turned on then DTD validation will be performed on each source document (to the XInclude processor) against their respective DTDs.

If both the validation feature and the schema validation feature are turned on then schema validation will be performed on the result infoset generated by the XInclude processor. DTD validation will be performed on each source document which contains a DTD. No DTD validation errors will be reported for source documents which have no DTD.

Why are xml:base attributes added, which make Schema validation fail?

According to the specification for XInclude, processors must add an xml:base attribute to elements included from locations with a different base URI. Without these attributes, the resulting infoset information would be incorrect. Unfortunately, these attributes make XInclude processing not transparent to Schema validation.

One solution to this is to modify your schema to allow xml:base attributes to appear on elements that might be included from different base URIs. There is a similar problem with xml:lang attributes that are added as a result of language fixup. If the addition of xml:base and/or xml:lang is undesired by your application, you can disable base URI fixup and language fixup so that these attributes will not be added.

Does the XInclude processor recognize xml:base attributes?

Yes. The XInclude specification requires processors to use the base URI (as specified in the XML Base recommendation) to resolve relative IRIs to compute the include location. Support for XML Base was added to the XInclude implementation in Xerces-J 2.6.0.

Does the XInclude processor perform language fixup?

Yes. The XInclude processor will preserve language information on a top-level included element by adding an xml:lang attribute if its include parent has a different [language] property. Support for language fixup was added to the XInclude implementation in Xerces-J 2.7.0.

Does the XInclude processor perform references property fixup?

Section 4.5.3 of the XInclude 1.0 W3C Recommendation describes fixup of the [references] property of an attribute information item. For IDREF/IDREFS the property contains an ordered list of element information items. Xerces provides no mechanism for accessing this property nor does it keep an internal representation. It should be noted that neither the SAX or DOM APIs have native support for the [references] property. For Xerces, references property fixup is a no-op.

Does the XInclude processor support XPointer?

Yes. The XInclude processor supports the XPointer Framework and the XPointer element() Scheme. The XPointer xpointer() Scheme is currently not supported.

What types of IDs are currently supported for XPointers?

For shorthand pointers and element() XPointers, currently only DTD-determined IDs are supported. schema-determined IDs may be supported in a future release.

Are the values of the content negotiation attributes used in an HTTP request?

Yes, the values of the accept and accept-language attributes from an include element are included as request properties in an HTTP request. Support for content negotiation when parse="xml" was added to the XInclude implementation in Xerces-J 2.7.0.

Will the XInclude processor process include elements from the 'http://www.w3.org/2003/XInclude' namespace?

No. The namespace for XInclude was changed back to http://www.w3.org/2001/XInclude in the Candidate Recommendation (April 2004). The http://www.w3.org/2003/XInclude namespace is no longer recognized.

xerces-2_11_0/docs/faq-xni.xml100644 0 0 16514 11474015642 13425 0ustar 0 0 What are all these strange "Augmentations" parameters I see in so many methods?

They're intended to provide a way to augment the basic XML infoset available from the non-Augmentation parameters in the callbacks. They can be used by a component to add arbitrary information to the streaming infoset, which can then be interpreted by some later component.

For instance, a component can be written to transmit the post schema validation infoset through Augmentations callbacks. This can then be translated into an XML representation. This is exactly what is done in the PSVI Writer and PSVI Configuration samples--see XNI sample documentation for details.

 How do I change the default parser configuration?

It is possible to override the default parser configuration used by the Xerces2 parsers without writing any code or changing the existing parser classes. Moreover, the DOM and SAX parsers created using the JAXP interfaces will use the specified parser configuration transparently and without need to call additional methods to set the parser configuration.

The DOM and SAX parsers decide which parser configuration to use in the following order:

  1. First, the org.apache.xerces.xni.parser.XMLParserConfiguration system property is queried for the class name of the parser configuration.
  2. Next, if a file called xerces.properties exists in the lib subdirectory of the JRE installation and the org.apache.xerces.xni.parser.XMLParserConfiguration property is defined it, then its value will be read from the file.
  3. Next, the org.apache.xerces.xni.parser.XMLParserConfiguration file is requested from the META-INF/services/ directory. This file contains the class name of the parser configuration.
  4. Finally, the &DefaultConfigLong; is used as the default parser configuration.
In all cases, the parser configuration class must have a public, no argument constructor so that it can be instantiated dynamically.

When using Java 2, it is not necessary to rebuild the Xerces jar files in order to override the default parser configuration using the first method. As long as a JAR file containing the appropriate file exists in the META-INF/services/ directory appears before the Xerces JAR files, the parser will use the new parser configuration.

The first method can always be used on the command line for the JVM by using the -D option. For example, to override the default parser configuration using a custom configuration named MyConfig, use the following command line:

java -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=MyConfig application_class In the Xerces distribution, what are the available parser configurations?

The default parser configuration is &DefaultConfigLong;. It and the other available parser configurations are described in the table below. All of them are located in the org.apache.xerces.parsers package.

ConfigurationDescription
DTDConfiguration A DTD-only configuration. Contains components appropriate to DTD-centric validation.
IntegratedParserConfiguration Extends StandardParserConfiguration by including a scanner that integrates both scanning of the document and binding namespaces.
NonValidatingConfiguration A non-validating configuration. It does not provide a conformant non-validating XML processor because it does not process the declarations in an internal subset besides checking their well-formedness.
SecurityConfiguration Extends the default configuration allowing Xerces to behave in a more security conscious manner by installing a SecurityManager.
SoftReferenceSymbolTableConfiguration Extends the default configuration allowing Xerces to handle usage scenarios where the names in the XML documents being parsed are mostly unique by installing a memory sensitive SymbolTable. The internalized strings stored in this SymbolTable are softly reachable and may be cleared by the garbage collector in response to memory demand.
StandardParserConfiguration Extends DTDConfiguration by adding support for XML schema validation.
XIncludeAwareParserConfiguration Extends XML11Configuration by providing support for XInclude. See the XInclude FAQ.
XML11Configuration Like IntegratedParserConfiguration except that it supports XML 1.1 in addition to XML 1.0.
XML11DTDConfiguration Like DTDConfiguration except that it supports XML 1.1 in addition to XML 1.0.
XML11NonValidatingConfiguration Like NonValidatingConfiguration except that it supports XML 1.1 in addition to XML 1.0.
XMLGrammarCachingConfiguration Extends the default configuration by providing a generic way of using Xerces' grammar caching facilities.
xerces-2_11_0/docs/faq-xs.xml100644 0 0 35304 11474015642 13257 0ustar 0 0 How do I validate against XML schema?

XML Schema 1.0 validation has been integrated with the regular SAXParser and DOMParser classes. No special classes are required to parse documents that use a schema.

For XML Schema 1.1 validation, you'll need to use the JAXP validation API, using the XSD 1.1 Schema factory. Here's an example:

import javax.xml.transform.Source; import javax.xml.transform.stream.StreamSource; import javax.xml.validation.Schema; import javax.xml.validation.SchemaFactory; import javax.xml.validation.Validator; ... StreamSource[] schemaDocuments = /* created by your application */; Source instanceDocument = /* created by your application */; SchemaFactory sf = SchemaFactory.newInstance( "http://www.w3.org/XML/XMLSchema/v1.1"); Schema s = sf.newSchema(schemaDocuments); Validator v = s.newValidator(); v.validate(instanceDocument);

You can also refer to the JAXP sample, SourceValidator, where you can validate XML documents against 1.1 schemas by specifying the "-xsd11" flag when running the sample.

Each document that uses XML Schema grammars must specify the location of the grammars it uses by using an xsi:schemaLocation attribute if they use namespaces, and an xsi:noNamespaceSchemaLocation attribute otherwise. These are usually placed on the root / top-level element in the document, though they may occur on any element; for more details see XML Schema Part 1 section 4.3.2. Here is an example with no target namespace:

<document xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation='document.xsd'> ... </document>

Here is an example with a target namespace. Note that it is an error to specify a different namespace than the target namespace defined in the Schema.

<document xmlns='http://my.com' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://my.com document.xsd'> ... </document>

Review the sample file, 'data/personal.xsd' for an example of an XML Schema grammar.

 How Xerces-J uses an XPath 2.0 engine for XML Schema 1.1 assertions and type alternatives?

XML Schema 1.1 'assertions' and 'type alternatives' require an XPath 2.0 processor for evaluation. For XSD 1.1 assertions, full XPath 2.0 support is required. For XSD 1.1 type alternatives, XML schema engines can provide full XPath 2.0 support or they can implement a smaller XPath 2.0 subset, as defined by the XSD 1.1 language. Within the type alternatives implementation, Xerces-J first attempts to compile the XPath expression with a native Xerces "XPath subset" parser. If parsing with the native Xerces "XPath subset" parser fails, Xerces-J transparently switches over to another processor which supports all of XPath 2.0. The native processor in Xerces-J was written for efficiency, so you will likely get better performance if your XPath expressions fall within the minimum subset defined by the XML Schema 1.1 specification. For full XPath 2.0 evaluation (for XSD 1.1 'assertions', and optionally for 'type alternatives'), Xerces-J uses the Eclipse/PsychoPath XPath 2.0 engine.

Xerces-J bundles a PsychoPath XPath 2.0 jar (which requires JDK 1.4 or later).

Users should be aware that more recent releases of the PsychoPath XPath engine may have better conformance to the W3C XPath 2.0 language than the PsychoPath XPath 2.0 jar that's bundled with Apache Xerces-J. Builds of the PsychoPath XPath 2.0 jar are available for download from following location, Eclipse Web Tools Platform (WTP) Project - The latest 'Released' or a 'Stable milestone' WTP version can be downloaded from here (from which the PsychoPath XPath 2.0 jar can be extracted). The latest PsychoPath XPath 2.0 engine builds at Eclipse require a minimum JDK level of 1.5. How does the XML Schema processor treat entities and CDATA sections?

According to the XML Infoset the infoset items contributing to the [character information item] are: characters in the document, whether literally, as a character reference, or within a CDATA section, or within Entity Reference. The XML Schema specification "requires as a precondition for assessment an information set as defined in [XML-Infoset]" (Appendix D) and thus Xerces might attempt to normalize data in an entity reference or CDATA section. To preserve character data within entity references and CDATA sections, turn off http://apache.org/xml/features/validation/schema/normalized-value feature.

Does Xerces provide access to the post schema validation infoset (PSVI)?

Xerces implements the XML Schema API specification that defines an API for accessing and querying the post schema validation infoset (PSVI) as defined in Contributions to the post-schema-validation infoset (Appendix C.2). This API also defines interfaces for loading XML schema documents.

For more information please refer to the interfaces.

The Xerces 2.6.2 release fixes a documentation bug in the XML Schema API. In particular in the XSModel interface the order of the parameters in getTypeDefinition, getNotationDeclaration, getModelGroupDefinition, getElementDeclaration, getAttributeDeclaration, getAttributeGroup methods have been changed from (String namespace, String name) to (String name, String namespace). What happened to the PSVI interfaces in org.apache.xerces.xni.psvi?

The PSVI interfaces which used to be part of the org.apache.xerces.xni.psvi and org.apache.xerces.impl.xs.psvi packages were modified and have been moved into the XML Schema API.

How do I access PSVI via XNI?

From within an XMLDocumentHandler, one can retrieve PSVI information while in the scope of the document handler start/end element calls:

import org.apache.xerces.xs.*; ... public void startElement(QName element, XMLAttributes attributes, Augmentations augs) { ElementPSVI elemPSVI = (ElementPSVI)augs.getItem("ELEMENT_PSVI"); // get PSVI items of this element out of elemPSVI short attemp = elemPSVI.getValidationAttempted(); short validity = elemPSVI.getValidity(); ... } For more information, please refer to the API documentation for the XML Schema API.

The above code shows how to retrieve PSVI information after elements/attributes are assessed. The other kind of information PSVI offers is the property [schema information]. This property exposes all schema components in the schema that are used for assessment. These components and the schema itself are represented by interfaces in the org.apache.xerces.xs package.

[schema information] property is only available on the endElement method for the validation root. When this method is called, information about various components can be retrieved by

import org.apache.xerces.xs.*; ... public void endElement(QName element, Augmentations augs) { ElementPSVI elemPSVI = (ElementPSVI)augs.getItem("ELEMENT_PSVI"); XSModel xsModel = elemPSVI.getSchemaInformation(); // get a list of [namespace schema information information item]s, // one for each namespace. XSNamespaceItemList nsItems = xsModel.getNamespaceItems(); ... // get an element declaration of the specified name and namespace XSElementDeclaration elemDecl = xsModel.getElementDeclaration (namespace, name); ... } How do I access PSVI via DOM?

Use the http://apache.org/xml/properties/dom/document-class-name property to set org.apache.xerces.dom.PSVIDocumentImpl as the implementation of the org.w3c.dom.Document interface. In the resulting DOM tree, you may cast org.w3c.dom.Element to the org.apache.xerces.xs.ElementPSVI and org.w3c.dom.Attr to the org.apache.xerces.xs.AttributePSVI.

import org.apache.xerces.xs.ElementPSVI; import org.apache.xerces.xs.XSModel; import org.apache.xerces.xs.XSNamedMap; ... Document document = parser.getDocument(); Element root = document.getDocumentElement(); // retrieve PSVI for the root element ElementPSVI rootPSVI = (ElementPSVI)root; // retrieve the schema used in validation of this document XSModel schema = rootPSVI.getSchemaInformation(); XSNamedMap elementDeclarations = schema.getComponents(XSConstants.ELEMENT_DECLARATION); // get schema normalized value String normalizedValue = rootPSVI.getSchemaNormalizedValue(); How do I access PSVI via SAX?

The Xerces SAX parser also implements the org.apache.xerces.xs.PSVIProvider interface. Within the scope of the methods handling the start (org.xml.sax.ContentHandler.startElement) and end (org.xml.sax.ContentHandler.endElement) of an element, applications may use the PSVIProvider to retrieve the PSVI related to the element and its attributes.

import org.apache.xerces.xs.PSVIProvider; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; ... SAXParserFactory factory = SAXParserFactory.newInstance(); SAXParser parser = factory.newSAXParser(); XMLReader reader = parser.getXMLReader(); PSVIProvider psviProvider = (PSVIProvider)reader; How do I access PSVI via the JAXP 1.4 Validation API?

Like the Xerces SAX parser the implementations of javax.xml.validation.Validator and javax.xml.validation.ValidatorHandler also implement the org.apache.xerces.xs.PSVIProvider interface. Within the scope of the methods handling the start (org.xml.sax.ContentHandler.startElement) and end (org.xml.sax.ContentHandler.endElement) of an element, applications may use the PSVIProvider to retrieve the PSVI related to the element and its attributes.

 How do I parse and analyze an XML schema?

Please, refer to the Examining Grammars FAQ.

 Can I parse and query XML Schema components in memory?

Yes, the XML Schema API specification defines an interface called XSLoader which provides methods for loading XML Schema documents into an XSModel. The XSImplementation interface provides a method to create an XSLoader using the DOM Level 3 Bootstraping mechanism. An application can get a reference to an XSImplementation using the getDOMImplementation method on the DOMImplementationRegistry object with the feature string "XS-Loader". To create an XSLoader you need to do something like this:

import org.w3c.dom.DOMImplementationRegistry; import org.apache.xerces.xs.XSImplementation; import org.apache.xerces.xs.XSLoader; ... // Get DOM Implementation using DOM Registry System.setProperty(DOMImplementationRegistry.PROPERTY, "org.apache.xerces.dom.DOMXSImplementationSourceImpl"); DOMImplementationRegistry registry = DOMImplementationRegistry.newInstance(); XSImplementation impl = (XSImplementation) registry.getDOMImplementation("XS-Loader"); XSLoader schemaLoader = impl.createXSLoader(null); ... xerces-2_11_0/docs/features.xml100644 0 0 76400 11474015642 13700 0ustar 0 0

If you have created a DOM document builder or a SAX parser using the JAXP interfaces, the following instructions tell you how to set features on document builders and SAX parsers created from the JAXP interfaces.

The DocumentBuilderFactory interface contains a setFeature(String,boolean) method which can be used to set features on the underlying parser. For example:

import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.DocumentBuilder; DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); try { dbf.setFeature("http://apache.org/xml/features/allow-java-encodings", true); } catch (ParserConfigurationException e) { System.err.println("could not set parser feature"); }

The SAXParserFactory interface contains a setFeature(String,boolean) method which can be used to set features on the underlying implementation of XMLReader. Once you create the SAXParser you can retrieve the underlying XMLReader allowing you to set and query features on it directly. For example:

import javax.xml.parsers.SAXParser; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; SAXParser parser = /* created from SAXParserFactory */; XMLReader reader = parser.getXMLReader(); try { reader.setFeature("http://xml.org/sax/features/allow-java-encodings", true); } catch (SAXException e) { System.err.println("could not set parser feature"); } Perform namespace processing: prefixes will be stripped off element and attribute names and replaced with the corresponding namespace URIs. By default, the two will simply be concatenated, but the namespace-sep core property allows the application to specify a delimiter string for separating the URI part and the local part. Do not perform namespace processing. If the validation feature is set to true, then the document must contain a grammar that supports the use of namespaces. The methods of the org.xml.sax.ext.EntityResolver2 interface will be used when an object implementing this interface is registered with the parser using setEntityResolver. The methods of the org.xml.sax.ext.EntityResolver2 interface will not be used. If the disallow DOCTYPE declaration feature is set to true org.xml.sax.ext.EntityResolver2.getExternalSubset() will not be called when the document contains no DOCTYPE declaration. Validate the document and report validity errors. Do not report validity errors. If this feature is set to true, the document must specify a grammar. By default, validation will occur against DTD. For more information, please, refer to the FAQ. If this feature is set to false, and document specifies a grammar that grammar might be parsed but no validation of the document contents will be performed. The parser will validate the document only if a grammar is specified. Validation is determined by the state of the validation feature. Turn on XML Schema validation by inserting an XML Schema validator into the pipeline. Do not report validation errors against XML Schema. Validation errors will only be reported if the validation feature is set to true. For more information, please, refer to the FAQ Checking of constraints on a schema grammar which are either time-consuming or memory intensive such as unique particle attribution will only occur if the schema full checking feature is set to true. Enable full schema grammar constraint checking, including checking which may be time-consuming or memory intensive. Currently, unique particle attribution constraint checking and particle derivation restriction checking are controlled by this option. Disable full constraint checking. This feature checks the Schema grammar itself for additional errors that are time-consuming or memory intensive. It does not affect the level of checking performed on document instances that use Schema grammars. Expose via SAX and DOM XML Schema normalized values for attributes and elements. Expose the infoset values XML Schema normalized values will be exposed only if both schema validation and validation features are set to true. Send XML Schema element default values via characters(). Do not send XML Schema default values in XNI XML Schema default values will be send via characters() if both schema validation and validation features are set to true. Augment Post-Schema-Validation-Infoset. Do not augment Post-Schema-Validation-Infoset. This feature can be turned off to improve parsing performance. xsi:type attributes will be ignored until a global element declaration has been found, at which point xsi:type attributes will be processed on the element for which the global element declaration was found as well as its descendants. Do not ignore xsi:type attributes. Enable generation of synthetic annotations. A synthetic annotation will be generated when a schema component has non-schema attributes but no child annotation. Do not generate synthetic annotations. Schema annotations will be laxly validated against available schema components. Do not validate schema annotations. All schema location hints will be used to locate the components for a given target namespace. Only the first schema location hint encountered by the processor will be used to locate the components for a given target namespace. Include external general entities. Do not include external general entities. Include external parameter entities and the external DTD subset. Do not include external parameter entities or the external DTD subset. Construct an optimal representation for DTD content models to significantly reduce the likelihood a StackOverflowError will occur when large content models are processed. Do not invest processing time to construct an optimal representation for DTD content models. Enabling this feature may cost your application some performance when DTDs are processed so it is recommended that it only be turned on when necessary. Enable checking of ID/IDREF constraints. Disable checking of ID/IDREF constraints. Validation will not fail if there are non-unique ID values or dangling IDREF values in the document. This feature only applies to schema validation. Enable identity constraint checking. Disable identity constraint checking. Check that each value of type ENTITY matches the name of an unparsed entity declared in the DTD. Do not check that each value of type ENTITY matches the name of an unparsed entity declared in the DTD. This feature only applies to schema validation. Report a warning when a duplicate attribute is re-declared. Do not report a warning when a duplicate attribute is re-declared. Report a warning if an element referenced in a content model is not declared. Do not report a warning if an element referenced in a content model is not declared. Report a warning for duplicate entity declaration. Do not report warning for duplicate entity declaration. Allow Java encoding names in XMLDecl and TextDecl line. Do not allow Java encoding names in XMLDecl and TextDecl line. A true value for this feature allows the encoding of the file to be specified as a Java encoding name as well as the standard ISO encoding name. Be aware that other parsers may not be able to use Java encoding names. If this feature is set to false, an error will be generated if Java encoding names are used. Attempt to continue parsing after a fatal error. Stops parse on first fatal error. The behavior of the parser when this feature is set to true is undetermined! Therefore use this feature with extreme caution because the parser may get stuck in an infinite loop or worse. Load the DTD and use it to add default attributes and set attribute types when parsing. Build the grammar but do not use the default attributes and attribute types information it contains. This feature is always on when validation is on. Load the external DTD. Ignore the external DTD completely. This feature is always on when validation is on. Notifies the handler of character reference boundaries in the document via the start/endEntity callbacks. Does not notify of character reference boundaries. Notifies the handler of built-in entity boundaries (e.g &amp;) in the document via the start/endEntity callbacks. Does not notify of built-in entity boundaries. A fatal error is thrown if the incoming document contains a DOCTYPE declaration. DOCTYPE declaration is allowed. Requires that a URI has to be provided where a URI is expected. Some invalid URI's are accepted as valid values when a URI is expected. Examples include: using platform dependent file separator in place of '/'; using Windows/DOS path names like "c:\blah" and "\\host\dir\blah"; using invalid URI characters (space, for example). It's recommended to set this feature to true if you want your application/documents to be truly portable across different XML processors. Enable XInclude processing. Do not perform XInclude processing. Perform base URI fixup as specified by the XInclude Recommendation. Do not perform base URI fixup. The XInclude processor will not add xml:base attributes. Perform language fixup as specified by the XInclude Recommendation. Do not perform language fixup. The XInclude processor will not add xml:lang attributes. Lazily expand the DOM nodes. Fully expand the DOM nodes. In the LSParser implementation the default value of this feature is false. When this feature is set to true, the DOM nodes in the returned document are expanded as the tree is traversed. This allows the parser to return a document faster than if the tree is fully expanded during parsing and improves memory usage when the whole tree is not traversed. Create EntityReference nodes in the DOM tree. The EntityReference nodes and their child nodes will be read-only. Do not create EntityReference nodes in the DOM tree. No EntityReference nodes will be created, only the nodes corresponding to their fully expanded substitution text will be created. This feature only affects the appearance of EntityReference nodes in the DOM tree. The document will always contain the entity reference child nodes. Include text nodes that can be considered "ignorable whitespace" in the DOM tree. Do not include ignorable whitespace in the DOM tree. The only way that the parser can determine if text is ignorable is by reading the associated grammar and having a content model for the document. When ignorable whitespace text nodes are included in the DOM tree, they will be flagged as ignorable. The ignorable flag can be queried by calling the Text#isElementContentWhitespace():boolean method. This feature is relevant only when the grammar is DTD. Report the original prefixed names and attributes used for namespace declarations. Do not report attributes used for Namespace declarations, and optionally do not report original prefixed names. All element names, prefixes, attribute names, namespace URIs, and local names are internalized using the java.lang.String#intern(String):String method. Names are not necessarily internalized. &ParserName; always internalizes all strings mentioned above using the String#intern() method. This feature can only be set to true. Report the beginning and end of parameter entities to a registered LexicalHandler. Do not report the beginning and end of parameter entities to a registered LexicalHandler. The document specified standalone="yes" in its XML declaration. The document specified standalone="no" in its XML declaration or the standalone document declaration was absent. The system identifiers passed to the notationDecl, unparsedEntityDecl, and externalEntityDecl events will be absolutized relative to their base URIs before reporting. System identifiers in declarations will not be absolutized before reporting. This feature does not apply to EntityResolver.resolveEntity(), which is not used to report declarations, or to LexicalHandler.startDTD(), which already provides the non-absolutized URI. Perform Unicode normalization checking (as described in section 2.13 and Appendix B of the XML 1.1 Recommendation) and report normalization errors. Do not report Unicode normalization errors. As there is currently no support for Unicode normalization checking, this feature can only be set to false. The Attributes objects passed by the parser in org.xml.sax.ContentHandler.startElement() implement the org.xml.sax.ext.Attributes2 interface. The Attributes objects passed by the parser do not implement the org.xml.sax.ext.Attributes2 interface. Xerces-J will always report Attributes objects that also implement org.xml.sax.ext.Attributes2 so the value of this feature will always be true. The Locator objects passed by the parser in org.xml.sax.ContentHandler.setDocumentLocator() implement the org.xml.sax.ext.Locator2 interface. The Locator objects passed by the parser do not implement the org.xml.sax.ext.Locator2 interface. Xerces-J will always report Locator objects that also implement org.xml.sax.ext.Locator2 so the value of this feature will always be true. When the namespace-prefixes feature is set to true, namespace declaration attributes will be reported as being in the http://www.w3.org/2000/xmlns/ namespace. Namespace declaration attributes are reported as having no namespace. The parser supports both XML 1.0 and XML 1.1. The parser supports only XML 1.0. The value of this feature will depend on whether the parser configuration owned by the SAX parser is known to support XML 1.1. Allows notationDecl and unparsedEntityDecl events to be sent in the XNI pipeline after the endDTD event has been sent. Ensures that notationDecl and unparsedEntityDecl events are not sent after the endDTD event has been sent (default SAX behaviour). The default value for this feature is true, except when using SAX, because SAX requires that no DTD events be sent after the endDTD event. Thus, in order to maintain SAX compatibility, this feature cannot be true by default for SAX. Setting this feature to false can result in loss of information, if notations and unparsed entities were needed to resolve references in the document. This feature is only relevant when XInclude processing is being done. Due to the nature of implementing XInclude in a stream-based API, it is not possible to know the complete set of required unparsed entities and notations before the endDTD event from the source document is sent. If an XIncludeHandler is not present in your pipeline, the value of this feature is irrelevant. This feature is currently experimental, and might be removed or changed in the next release. If you have any concerns or suggestions about its use, please contact the j-users@xerces.apache.org mailing list. xerces-2_11_0/docs/install.xml100644 0 0 36042 11474015641 13525 0ustar 0 0

&ParserName; is packaged as a ZIP file for all platforms and operating systems. The parser release is also packaged as Tar GZip files as a convenience for UNIX users. You can extract the ZIP files using the Java jar command to unpack the distribution.

jar xf &ParserName;-bin.&parserversion;.zip jar xf &ParserName;-src.&parserversion;.zip jar xf &ParserName;-tools.&parserversion;.zip

All of these commands create a sub-directory called "&parserdir;" in the current directory, except for the command to unpack the "tools" distribution, since you may install this anywhere you like.

LICENSE License for &ParserName;
NOTICE NOTICE file for &ParserName;
LICENSE.resolver.txt License for the XML Commons Resolver
NOTICE.resolver.txt NOTICE file for the XML Commons Resolver
LICENSE.serializer.txt License for the Apache Xalan serializer
NOTICE.serializer.txt NOTICE file for the Apache Xalan serializer
LICENSE-SAX.html SAX License
LICENSE.DOM-documentation.html W3C Document License
LICENSE.DOM-software.html W3C Software License
Readme.html Web page redirect to docs/html/index.html
resolver.jar Jar file containing the XML Commons Resolver. Currently Resolver 1.2 is distributed with &ParserName;.
serializer.jar Jar file containing the Apache Xalan serializer. Currently the serializer included in Xalan 2.7.1 is distributed with &ParserName;.
xercesImpl.jar Jar file containing all the parser class files that implement one of the standard APIs supported by the parser
xml-apis.jar Jar file containing all the standard APIs implemented by the parser. Currently &ParserName; supports DOM level 3, SAX 2.0.2, and the javax.xml.datatype, javax.xml.parsers and javax.xml.validation parts of JAXP 1.4.
xercesSamples.jar Jar file containing all sample class files
data/ Directory containing sample XML data files
docs/ Directory containing documentation
docs/javadocs/ Directory containing Javadoc API for parser framework
samples/ Directory containing the source code for the samples
To use &ParserName; you do not need the source files. However, if you want to recompile the sources you need to download the source package and have the contents of the tools package (or equivalent) available. xerces.jar is no longer available in the main distribution. You can still download this jar from deprecated distribution. xerces.jar is a Jar file that contains all the parser class files (i.e., it contains the intersection of the contents of xercesImpl.jar and xml-apis.jar).
LICENSE License for &ParserName;
NOTICE NOTICE file for &ParserName;
LICENSE.resolver.txt License for the XML Commons Resolver
NOTICE.resolver.txt NOTICE file for the XML Commons Resolver
LICENSE.serializer.txt License for the Apache Xalan serializer
NOTICE.serializer.txt NOTICE file for the Apache Xalan serializer
LICENSE-SAX.html SAX License
LICENSE.DOM-documentation.html W3C Document License
LICENSE.DOM-software.html W3C Software License
build.bat Batch file for invoking Ant build for Windows users
build.sh Shell script for invoking Ant build for UNIX users
build.xml Ant build file -- read README file before building
README Build instructions
Readme.html Web page redirect required for building documentation
data/ Directory containing sample XML data files
docs/ Directory containing documentation, in XML form
samples/ Directory containing source code for samples
src/ Directory containing source code for parser and supplemental APIs
In order to compile the source code using Ant or to build the release distributions yourself, you must have the contents of &ParserName;-tools.&parserversion;.zip on your classpath; i.e., you will need access to a version of Ant, Xalan, StyleBook and an XML parser such as Xerces. For ease of use, we recommend extracting &ParserName;-tools.&parserversion;.zip in your Xerces root directory; the build.sh and build.bat scripts are written for this case.
ant*.jar Jar files containing Apache Ant 1.7.1 for building Xerces-J
ant*.LICENSE.txt License for Apache Ant 1.7.1
ant*.NOTICE.txt NOTICE file for Apache Ant 1.7.1
junit.jar Jar file containing JUnit 3.8.1
junit.LICENSE.html License for JUnit 3.8.1
resolver.jar Jar file containing the XML Commons Resolver. Currently Resolver 1.2 is distributed with &ParserName;.
resolver.LICENSE.txt License for the XML Commons Resolver
resolver.NOTICE.txt NOTICE file for the XML Commons Resolver
serializer.jar Jar file containing the Apache Xalan serializer. Currently the serializer included in Xalan 2.7.1 is distributed with &ParserName;.
serializer.LICENSE.txt License for the Apache Xalan serializer
serializer.NOTICE.txt NOTICE file for the Apache Xalan serializer
stylebook-1.0-b2.jar Jar file containing the Apache Stylebook for building the Xerces-J documentation
stylebook-1.0-b2.LICENSE.txt License for the Apache Stylebook
xalan.jar Jar file containing Apache Xalan 2.7.1 (required by the Apache Stylebook for building the Xerces-J documentation)
xalan.LICENSE.txt License for Apache Xalan 2.7.1
xalan.NOTICE.txt NOTICE file for Apache Xalan 2.7.1
xercesImpl.jar Jar file containing Apache Xerces-J 2.9.1 (required by Apache Ant for building Xerces-J and the Apache Stylebook for building its documentation)
xercesImpl.LICENSE.txt License for Apache Xerces-J 2.9.1
xercesImpl.NOTICE.txt NOTICE file for Apache Xerces-J 2.9.1
xml-apis.jar Jar file containing Apache XML Commons External 1.4.01 (required by Apache Ant for building Xerces-J)
xml-apis.LICENSE.txt License for Apache XML Commons External 1.4.01
xml-apis.NOTICE.txt NOTICE file for Apache XML Commons External 1.4.01
xml-commons-external-src.zip Bundle containing the source of Apache XML Commons External 1.4.01 (required for building the Javadoc)
xml-commons-external-src.LICENSE.txt License for Apache XML Commons External 1.4.01
xml-commons-external-src.NOTICE.txt NOTICE file for Apache XML Commons External 1.4.01
bin/ Contains scripts for Ant, a specialized Ant target for building Xerces-J and a taglet for generating custom Javadoc from @xerces.internal and @xerces.experimental tags in the source code.
The xercesImpl.jar in the tools package is provided for building Xerces-J through Ant. This jar will always be older than the current release of Xerces-J and is not intended for application use.

In order to accommodate the very common case in which Xerces is used with an XSLT processor such as Xalan, between Xerces 2.0.0 beta 3 and beta 4 a change in the default organization of Xerces' jar files was introduced. As well as the xercesSamples.jar file, which we still produce, Xerces formerly came with a file called xerces.jar. This file contained all of the parser's functionality. Two files are now included: xercesImpl.jar, our implementation of various APIs, and xml-apis.jar, the APIs themselves. This was done so that, if your XSLT processor ships with APIs at the same level as those supported by &ParserName;, you can avoid putting xml-apis.jar on your classpath.

Should you wish to use the xerces.jar instead, we have included several Ant targets for backward compatibility. An "Ant target" is an argument given to Ant, our build tool, that tells it which portions of the build.xml file to apply.

If you are on a Windows system and you wish to get only the xerces.jar file, you would execute build.bat deprecatedjars.

If you want to regenerate new versions of the Xerces binary, source and tools distributions with the old-style jar files, you would execute build.bat deprecatedall. The situation is analogous for Unix users, except that build.sh would be used instead of build.bat.

For further information and more options, please look inside build.xml itself; all possibilities are documented there.

In order to provide security-conscious users with the best possible assurance that the Xerces distribution they have downloaded is official, "signatures" are provided for all 6 Xerces packages produced in each release. A signature is produced with cryptographic software (such as PGP or GNUPG). The cryptographic software is used to apply an algorithm that uses the secret "key" of a Xerces committer to generate a unique file from each Xerces distribution. The Xerces committer then makes a "public" key available, which the user can use, in conjunction with the downloaded distribution and the accompanying signature, to verify that the distribution was actually produced by that committer.

In order to verify the legitimacy of Xerces distributions you download, these steps should be followed:

  1. Get a copy of PGP or GNUPG from the above URL's.
  2. Obtain the signature of the Xerces package you wish to verify. For instance, if you want to verify the legitimacy of Xerces-bin.x.y.z.tar.gz, download the Xerces-bin.x.y.z.tar.gz.asc file from the same location as the original file was obtained.
  3. Obtain a copy of the public key of the Xerces committer. While most committers have posted their keys to public "key servers", probably the easiest place to get them from is SVN. The public keys of all Xerces committers who post releases are available from the file called KEYS located in the root directory of the http://svn.apache.org/repos/asf/xerces/java/trunk/ repository.
  4. Add these keys to your "public" keyring. In GNUPG, you'd do this with a command like gpg --import KEYS.
  5. Issue the command for verifying signatures appropriate for the cryptographic software you've chosen. For GNUPG, this would be gpg --verify Xerces-J-foo.x.y.z.ext.asc Xerces-J-foo.x.y.z.ext.

Note that, in general, it won't be necessary to acquire new copies of public keys to verify signatures for each Xerces release. This will only be necessary if a new Xerces committer has published the release.

xerces-2_11_0/docs/limitations.xml100644 0 0 2742 11474015641 14373 0ustar 0 0

This is a list of the limitations in this release of &ParserName;. There is also a list of XML Schema Limitations.

xerces-2_11_0/docs/properties.xml100644 0 0 34271 11474015642 14256 0ustar 0 0

If you have created a DOM document builder or a SAX parser using the JAXP interfaces, the following instructions tell you how to set properties on document builders and SAX parsers created from the JAXP interfaces.

The DocumentBuilderFactory interface contains a setAttribute(String,Object) method which may provide a means to set properties on the underlying parser. When using Xerces, you can set the value of a property with this method. For example:

import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.DocumentBuilder; DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); String id = "http://apache.org/xml/properties/dom/document-class-name"; Object value = "org.apache.xerces.dom.DocumentImpl"; try { dbf.setAttribute(id, value); } catch (IllegalArgumentException e) { System.err.println("could not set parser property"); }

The SAXParser interface contains a setProperty(String,Object) method which can be used to set properties on the underlying implementation of XMLReader. You can also retrieve the underlying XMLReader from the SAXParser allowing you to set and query properties on it directly. For example:

import javax.xml.parsers.SAXParser; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; SAXParser parser = /* created from SAXParserFactory */; XMLReader reader = parser.getXMLReader(); String id = "http://apache.org/xml/properties/input-buffer-size"; Object value = new Integer(2048); try { reader.setProperty(id, value); } catch (SAXException e) { System.err.println("could not set parser property"); } Get the string of characters associated with the current event. If the parser recognizes and supports this property but is not currently parsing text, it should return null. java.lang.String This property is currently not supported because the contents of the XML string returned by this property is not well defined. The XML Schema Recommendation explicitly states that the inclusion of schemaLocation/noNamespaceSchemaLocation attributes is only a hint; it does not mandate that these attributes must be used to locate schemas. Similar situation happens to <import> element in schema documents. This property allows the user to specify a list of schemas to use. If the targetNamespace of a schema (specified using this property) matches the targetNamespace of a schema occurring in the instance document in schemaLocation attribute, or if the targetNamespace matches the namespace attribute of <import> element, the schema specified by the user using this property will be used (i.e., the schemaLocation attribute in the instance document or on the <import> element will be effectively ignored). java.lang.String The syntax is the same as for schemaLocation attributes in instance documents: e.g, "http://www.example.com file_name.xsd". The user can specify more than one XML Schema in the list. This property allows the user to specify an XML Schema with no namespace. java.lang.String The syntax is a same as for the noNamespaceSchemaLocation attribute that may occur in an instance document: e.g."file_name.xsd". The user may specify only one XML Schema. For more information see the documentation for the http://apache.org/xml/properties/schema/external-schemaLocation property. A QName or XSElementDeclaration object representing the top-level element declaration used when validating the root element of a document or document fragment (also known as the validation root). If the value of this property is non-null the validation root will be validated against the specified element declaration regardless of the actual name of the root element in the instance document. If the value is a QName and a element declaration cannot be found an error will be reported. javax.xml.namespace.QName or org.apache.xerces.xs.XSElementDeclaration If the 'root-type-definition' property has been set this property takes precedence if its value is non-null. If the value specified is an XSElementDeclaration it must be an object obtained from Xerces and must also be an object which is known to the schema validator, for example one which would be returned from an XMLGrammarPool. If these constraints are not met a ClassCastException may be thrown or processing of substitution groups, xsi:type and wildcards may fail to locate otherwise available schema components. A QName or XSTypeDefinition object representing the top-level type definition used when validating the root element of a document or document fragment (also known as the validation root). If the value of this property is non-null and the 'root-element-declaration' property is not set the validation root will not be validated against any element declaration. If the value is a QName and a type definition cannot be found an error will be reported. javax.xml.namespace.QName or org.apache.xerces.xs.XSTypeDefinition If the 'root-element-declaration' property has been set this property is ignored. Prior to &ParserName; 2.10.0 setting the value of this property to an XSTypeDefinition was not supported. If the value specified is an XSTypeDefinition it must be an object obtained from Xerces and must also be an object which is known to the schema validator, for example one which would be returned from an XMLGrammarPool. If these constraints are not met a ClassCastException may be thrown or processing of substitution groups, xsi:type and wildcards may fail to locate otherwise available schema components. The size of the input buffer in the readers. This determines how many bytes to read for each chunk. java.lang.Integer Some tests indicate that a bigger buffer size can improve the parsing performance for relatively large files. The default buffer size in Xerces is 2K. This would give a good performance for small documents (less than 10K). For documents larger than 10K, specifying the buffer size to 4K or 8K will significantly improve the performance. But it's not recommended to set it to a value larger than 16K. For really tiny documents (1K, for example), you can also set it to a value less than 2K, to get the best performance. There are some conditions where the size of the parser's internal buffers may be increased beyond the size specified for the input buffer. This would happen in places where the text in the document cannot be split, for instance if the document contains a name which is longer than the input buffer. The locale to use for reporting errors and warnings. When the value of this property is null the platform default returned from java.util.Locale.getDefault() will be used. java.util.Locale If no messages are available for the specified locale the platform default will be used. If the platform default is not English and no messages are available for this locale then messages will be reported in English. It is possible to create XML documents whose processing could result in the use of all system resources. This property enables Xerces to detect such documents, and abort their processing. org.apache.xerces.util.SecurityManager The org.apache.xerces.util.SecurityManager class contains a number of methods that allow applications to tailor Xerces's tolerance of document constructs that could result in the heavy consumption of system resources (see the javadoc of this class for details). Default values that should be appropriate for many environments are provided when the class is instantiated. Xerces will not behave in a strictly spec-compliant way when this property is set. By default, this property is not set; Xerces's behaviour is therefore strictly spec-compliant by default. The current DOM element node while parsing. org.w3c.dom.Element This property is useful for determining the location with a DOM document when an error occurs. The fully qualified name of the class implementing the org.w3c.dom.Document interface. The implementation used must have a zero argument constructor. java.lang.String When the document class name is set to a value other than the name of the default document factory, the deferred node expansion feature does not work. Set the handler for DTD declarations. org.xml.sax.ext.DeclHandler Set the handler for lexical parsing events. org.xml.sax.ext.LexicalHandler The DOM node currently being visited, if SAX is being used as a DOM iterator. If the parser recognizes and supports this property but is not currently visiting a DOM node, it should return null. org.w3c.dom.Node This property is only for SAX parser implementations used as DOM tree walkers. Currently, Xerces does not have this functionality. A literal string describing the actual XML version of the document, such as "1.0" or "1.1". java.lang.String This property may only be examined during a parse after the startDocument callback has been completed. xerces-2_11_0/docs/readme.xml100644 0 0 21173 11474015642 13314 0ustar 0 0

Welcome to the future! Xerces2 is the next generation of high performance, fully compliant XML parsers in the Apache Xerces family. This new version of Xerces introduces the Xerces Native Interface (XNI), a complete framework for building parser components and configurations that is extremely modular and easy to program.

The Apache Xerces2 parser is the reference implementation of XNI but other parser components, configurations, and parsers can be written using the Xerces Native Interface. For complete design and implementation documents, refer to the XNI Manual.

Xerces2 is a fully conforming XML Schema 1.0 processor. A partial experimental implementation of the XML Schema 1.1 Structures and Datatypes Working Drafts (December 2009) and an experimental implementation of the XML Schema Definition Language (XSD): Component Designators (SCD) Candidate Recommendation (January 2010) are provided for evaluation. For more information, refer to the XML Schema page.

Xerces2 also provides a complete implementation of the Document Object Model Level 3 Core and Load/Save W3C Recommendations and provides a complete implementation of the XML Inclusions (XInclude) W3C Recommendation. It also provides support for OASIS XML Catalogs v1.1.

Xerces2 is able to parse documents written according to the XML 1.1 Recommendation, except that it does not yet provide an option to enable normalization checking as described in section 2.13 of this specification. It also handles namespaces according to the XML Namespaces 1.1 Recommendation, and will correctly serialize XML 1.1 documents if the DOM level 3 load/save APIs are in use.

The &ParserNameLong; &ParserVersion; supports the following standards and APIs:

According to the DOM Level 3 specification and DOM Level 2 errata the createElementNS and createAttributeNS methods convert empty string namespaceURI to null. Please, let us know if this change affects your application.

The &ParserNameLong; &ParserVersion; expands on its experimental support for XML Schema 1.1 by providing implementations for the simplified complex type restriction rules (also known as subsumption), xs:override and a few other XML Schema 1.1 features. This release also introduces experimental support for XML Schema Component Designators (SCD). It fixes several bugs which were present in the previous release and also includes a few other minor enhancements.

For a more complete list of changes, refer to the Release Information page.

Xerces2 is a nearly complete rewrite of the Xerces 1.x codebase in order to make the code cleaner, more modular, and easier to maintain. It includes a completely redesigned and rewritten XML Schema validation engine. Applications using only the standard interfaces such as JAXP, DOM, and SAX should not see any differences.

The &ParserName; &ParserVersion; release is available in source code and precompiled binary (JAR files) form. Both &ParserName; packages are made available under the Apache Software License.

xerces-2_11_0/docs/releases.xml100644 0 0 272224 11474015642 13707 0ustar 0 0

This release expands on Xerces' experimental support for XML Schema 1.1 by providing implementations for the simplified complex type restriction rules (also known as subsumption), xs:override and a few other XML Schema 1.1 features. This release also introduces experimental support for XML Schema Component Designators (SCD). It fixes several bugs which were present in &ParserName; 2.10.0 and also includes a few other minor enhancements.

Implemented XML Schema 1.1's simplified complex type restriction rules (also known as subsumption). Added support for XML Schema 1.1's overriding component definitions (<xs:override>). Added experimental support for a parser and evaluator for XML Schema Component Designators (SCD). Implemented support for the vc:typeAvailable, vc:typeUnavailable, vc:facetAvailable and vc:facetUnavailable attributes for conditional inclusion processing in XML Schema 1.1 documents. Implemented support for allowing xs:group as a child of xs:all in XML Schema 1.1 documents. Made several enhancements to the support for assertions in the XML Schema 1.1 implementation. Improved the ways in which the XML Schema API exposes values and identity constraint information. Fixed a bug where XMLSchemaValidator.findSchemaGrammar() was not getting called for substitution groups. Fixed a bug in the regular expression support which was introduced in the previous release. See JIRA Issue XERCESJ-1456 for details. Fixed multiple issues with decimal precision in the processing of xs:precisionDecimal values. Fixed various bugs and made various improvements.

This release introduces experimental support for the XML Schema 1.1 Structures and Datatypes (December 2009) Working Drafts. It also contains an implementation of the parser related portions of JAXP 1.4, including partial support for StAX 1.0 (javax.xml.stream.events only) and a complete implementation of the DOM Element Traversal API. It contains fixes for several bugs which were present in &ParserName; 2.9.1, as well as a few other enhancements and performance improvements.

Added experimental support for XML Schema 1.1 (refer to the documentation for a list of features supported). Implemented enhancements to javax.xml.validation that were introduced by JAXP 1.4, including support for StAXSource/StAXResult as an input/output to the JAXP Validator, StreamResult as an output to the JAXP Validator and StAXSource as an input to the SchemaFactory. Added support for the StAX 1.0 event API (javax.xml.stream.events). Added support for the Element Traversal API (org.w3c.dom.ElementTraversal). Implemented a property for starting schema assessment from a specific element declaration and enhanced the existing property for starting schema assessment from a type definition to accept a javax.xml.namespace.QName as a value. Added a property for specifying the locale to use when reporting error and warning messages. Added support for matching multi-digit back references in regular expressions. Added a method to the ItemPSVI interface in the XML Schema API to expose error messages corresponding to the error codes that were already available in the PSVI. Implemented native support for UTF-16. Improved usability of the XML Schema API by updating XSNamedMap and all of the list type interfaces to extend java.util.Map and java.util.List respectively. Improved performance by eliminating excessive calls to XMLSchemaValidator.findSchemaGrammar() when processing local elements with no namespace. Improved recovery from schema loading errors. Improved performance of Element.getBaseURI() when the depth of the node to the document root is longer. Implemented several improvements in the DOM implementation to help the garbage collector reclaim objects which are no longer reachable by the application but were held on to strongly by the Document node. Improved the messages reported for minOccurs/maxOccurs related schema validation errors. Fixed problems with regular expression matching where the parser would hang or cause a stack overflow exception. Fixed a problem where the LSParser repeatedly overwrote a text node child of an element (rather than appending) when there are multiple text nodes in the input. Fixed an infinite loop in XMLScanner which could allow remote attackers to launch a denial of service attack (CVE-2009-2625). Fixed a bug in XSDateTime where getXMLGregorianCalendar() would lose precision for fractional digits and insert time-zones where there are none. Fixed a bug in the DOM implementation where a static text Node field in AttrImpl broke thread-safety of mutations in independent documents from within an event listener. This was also a potential memory leak. Fixed a bug in the SoftReferenceSymbolTable which could cause it to get stuck in an infinite loop. Fixed a bug which could cause an ArrayIndexOutOfBoundsException to be thrown when adopting a node from a deferred DOM. Fixed various bugs and made various improvements.

This release fixes several bugs which were present in Xerces-J 2.9.0. It also includes a few minor enhancements and performance improvements.

Added support for creating UIEvents and MouseEvents through the DOM Level 2 Events API. Improved the reporting of character conversion errors. The CharConversionException which triggered the fatal error is now available from SAXException.getException(). Reduced the performance penalty for using an EOFException internally to signal to the scanner that the end of the document has been reached. The exception is now cached, avoiding the expensive fillInStackTrace() on creation. Improved the performance of the XMLGregorianCalendar implementation. Implemented improvements in the processing of large minOccurs/maxOccurs on element/wildcard particles which once caused OutOfMemoryErrors to occur during validation. Note that an OutOfMemoryError may still occur if the minOccurs/maxOccurs are nested or appear on a sequence or choice model group. Improved the algorithm for checking the Unique Particle Attribution constraint so that it no longer causes an OutOfMemoryError for content models with large maxOccurs values. Note that this only applies to the checking of schema validity. An OutOfMemoryError may still occur if the schema contains large maxOccurs and is used to validate an instance document. Completed the implementation of XML Schema erratum E2-67. Implemented XML 1.0 Third Edition erratum E13. Fixed bugs in the implementation of Document.normalizeDocument() where it was not correctly re-evaluating Element.schemaTypeInfo, Attr.schemaTypeInfo, IDness or the [element content whitespace] property of text nodes when validating against a DTD or XML Schema. Fixed a thread-safety bug which could cause an ArrayIndexOutOfBoundsException or a NullPointerException to be thrown during DTD validation if a grammar pool is shared between multiple parser instances. Fixed a bug in the DOMConfiguration of a Document where it was processing the "schema-location" parameter as an atomic URI value instead of a whitespace separated list of URIs. Fixed a bug in the XInclude implementation where the Locator would report the location of the xi:include element in the top-level document as the location of all the document events in the included document or fragment. Fixed a bug in the JAXP schema validator which caused it to fail with a third-party DOM Level 3 implementation whose nodes can only be tested for identity using isSameNode(). Fixed several bugs in the XML schema processor which were exposed by running the W3C's XML Schema 1.0 2nd Edition test suite. Fixed several bugs in the DOM Level 2 Traversal and Range implementation. Fixed various bugs and made various improvements.

As of this release, Xerces and Xalan now share a common serialization codebase. The DOM Level 3 serialization support which was in Xerces was migrated into the Xalan serializer and Xerces' native serializer was deprecated. In this release we also upgraded the xml-commons resolver to v1.2 (which provides support for OASIS XML Catalogs v1.1), introduced a few minor features and fixed several bugs.

Migrated the DOM Level 3 serialization support onto a common serialization codebase shared with Xalan and deprecated Xerces' native serializer. Upgraded the xml-commons resolver to v1.2. This new version of the resolver adds support for OASIS XML Catalogs v1.1. Created a new parser configuration which uses a memory sensitive SymbolTable which can handle usage scenarios where the names in the XML documents being parsed are mostly unique. The internalized strings stored in this SymbolTable are softly reachable and may be cleared by the garbage collector in response to memory demand. Updated the schema loader so that it can now process schema documents with an XML 1.1 declaration. Fixed several bugs in the checking of schema type restrictions that involve substitution groups. Fixed a bug in Xerces' regular expression support where patterns containing "$" and "^" were being interpreted as anchors in a schema context. Fixed a bug in the XPath matcher for identity constraints which allowed steps containing NCName:* to select element or attribute names which do not match the specified namespace. Fixed a bug in the XPath parser for identity constraints which caused field and selector XPaths containing the non-abbreviated form of the child and attribute axes to be reported as invalid. Fixed a bug which allowed the JAXP SchemaFactory to mutate a user supplied DOM input. Fixed a bug which caused the JAXP 1.2 method for schema validation to produce DTD validation errors when XInclude processing is enabled. Fixed various bugs and made various improvements.

This release fixes several bugs which were present in Xerces-J 2.8.0. It also includes a few minor enhancements and performance improvements.

Implemented native support for the ISO-8859-1 encoding. Added a method to XSModel which returns a list containing the members of the substitution group for a given element declaration. Improved the performance of Xerces' optimized readers (for small documents) by recycling their byte buffers. Modified the DocumentBuilder and LSParser implementations so that they drop their internal references to the DOM they just built. If an application is pooling parsers this will allow the garbage collector to reclaim the Document and all of its nodes if the application no longer has any references to it. Fixed numerous schema annotation related bugs including those introduced in Xerces-J 2.8.0 which caused NPEs to be thrown from several of the getAnnotation() methods in the XML Schema API. Fixed a DOM bug which caused the internal subset of a DocumentType node to be omitted from a cloned Document. Fixed a bug in Xerces' regular expression support involving patterns starting with '.'. Fixed a bug which caused the DOM builder to drop all of the text in the document if grammar caching is enabled and the document being processed contains both an internal and an external DTD subset. Fixed a schema bug which allowed defaulted attributes with the same local name to overwrite each other. Fixed a bug which caused a schema document to be loaded multiple times if it was both included and redefined. This made it possible for the redefined components to be incorrectly overwritten by the original ones from the include. Fixed a bug in Xerces' native serializer which caused documents containing supplemental characters in attribute values to be written incorrectly. Fixed a bug in the XInclude processor which in some instances caused content to be omitted from the result if an element() XPointer is specified on an include element. Fixed various bugs and made various improvements.

This release introduces several new validation related features and provides enhancements to the XML schema annotation support. All of the schema component interfaces in the XML Schema API now have a getAnnotations() method which returns a list of XSAnnotations. This includes annotations on particles and attribute uses which were previously "lost". In addition, in this release we implemented support for pretty-printing in the LSSerializer, repaired the warn-on-undeclared-elemdef feature which had been broken for several releases and fixed many other bugs.

Added a getAnnotations() method to each of the component interfaces in the XML Schema API (including XSParticle and XSAttributeUse) and implemented the support for the new methods. Implemented a property for starting schema assessment from a specific type definition. Implemented features for disabling ID/IDREF, unparsed entity and identity constraint checking. Implemented a feature which instructs the schema validator to ignore xsi:type attributes until a global element declaration has been found. Modified the JAXP Validation API implementation so that it propagates features set on the SchemaFactory to the Schemas created from the factory and in turn ValidatorHandlers and Validators constructed from those Schema objects (as clarified by JAXP 1.4). Implemented the DOM Level 3 Load and Save format-pretty-print parameter. Fixed the warn-on-undeclared-elemdef feature which had been broken for many releases. Implemented a feature which allows the parser to process DTDs containing large content models which under normal operation may cause a StackOverflowError to occur. Improved the performance and memory usage of XSAnnotation.writeAnnotation(). Implemented XML Schema erratum E2-66. Fixed bugs in the implementation of Document.normalizeDocument() which caused DTD validation to fail in numerous scenarios. Fixed a bug where schema validation performed in Document.normalizeDocument() was adding default attributes without setting their owner element or firing mutation events. Fixed a bug which caused the JAXP 1.2 method for schema validation to fail when the parser is reused. Fixed a bug which caused a ClassCastException to be thrown when adopting a node from a deferred DOM into a non-deferred DOM. Fixed the dtdjars build target which had been broken for several releases. Improved identity constraint error messages. Fixed various bugs and made various improvements.

This release fixes one XInclude bug and several schema related bugs which were present in Xerces-J 2.7.0.

Fixed an inconsistency in the validation behaviour of the parser when XInclude processing is enabled and the validation and schema validation features are also enabled. Fixed a bug where in a DOM Level 3 context with schema validation enabled, not all schema constraints (such as unique particle attribution) were being checked. Fixed bugs which allowed various invalid lexical values to be accepted by the schema validator for the following types: double, date, float, gDay, gMonthDay, gMonth and gYearMonth. Fixed a schema bug where errors would be reported for comments and processing instructions which appear as the children of an element declared to have empty content. Fixed a bug which caused an NPE to be thrown for a namespace declaration such as xmlns="" which appeared on an ancestor element of an <annotation>.

This release provides a complete implementation of the parser related portions of JAXP 1.3 and also brings Xerces into compliance with SAX 2.0.2, the DOM Level 3 Core and Load/Save W3C Recommendations, the XML Inclusions (XInclude) Version 1.0 W3C Recommendation and the XML Schema 1.0 Structures and Datatypes Second Edition W3C Recommendations.

&ParserName; 2.7.0 incorporates two minor changes to the Xerces Native Interface (documented below). A new package org.apache.xerces.xs.datatypes has been added to Xerces' XML Schema API that provides a full schema datatype to object mapping. In addition, in this release we introduced many new parser features, improved parser performance in several areas and fixed many bugs.

Implemented the following packages defined by JAXP 1.3: javax.xml.datatype, javax.xml.parsers and javax.xml.validation. Defined and implemented interfaces (org.apache.xerces.xs.datatypes) for accessing actual values. Implemented a feature that instructs the schema processor to use all schema location hints for a given target namespace when locating components. Implemented partial experimental support for the first working draft of XML Schema 1.1 Structures and Datatypes. Implemented features for configuring whether the XInclude processor performs base URI fixup and/or language fixup. Implemented the XInclude Recommendation (December 2004). Fixed a bug which caused the DTD validator to be activated when using the XInclude processor with schema validation turned on. Modified the XNI XMLLocator interface to include getCharacterOffset and getXMLVersion. Added a getCharacterOffset method to XMLParseException. Made various modifications to support the reporting of character offsets in XNI and DOM. Implemented SAX 2.0.2 and SAX2 Extensions 1.1. Fixed SAX conformance bugs including one concerning skipped entities. Implemented a feature that allows schema annotations to be validated. Added support for generating synthetic annotations when a schema component has non-schema attributes but no child annotation. Fixed numerous schema related bugs. Reimplemented Text.replaceWholeText and TypeInfo.isDerivedFrom according to the DOM Level 3 Core Recommendation. Fixed various DOM Level 3 bugs. Fixed numerous bugs in the DOM Level 2 Events and Traversal and Range implementation. Created two new parser configurations that support XML 1.1. Improved the performance of the SymbolTable, processing of attribute values and parsing of relative URIs. Added support for EntityResolver2 and LSResourceResolver to XMLCatalogResolver. Fixed a potential memory leak in the ObjectFactory classes which in some circumstances allowed input streams to never be closed. Fixed a thread-safety bug concerning identity constraints which caused spurious errors about duplicate field matches to be reported. Fixed various bugs. This release fixes several bugs which were present in Xerces-J 2.6.1. It also provides a few minor performance improvements. Fixed a bug in the specification of the XML Schema API. Some of the method signatures did not match the signatures in the implementation. Fixed a bug introduced in 2.6.1 which caused the XMLSerializer to automatically expand entity references and convert CDATA sections to text. Fixed a possible security hole regarding class loading. Improved class initialization for the XMLChar and XML11Char classes to reduce the cost of loading Xerces. Fixed a SAX conformance bug involving spurious prefix mapping events with namespace support turned off. Made message localization changes. Fixed schema related bugs. Fixed various bugs. This release provides support for OASIS XML Catalogs and includes several bug fixes for XML 1.1, XML Schema and DOM Level 3 Core and Load/Save. It also contains several performance improvements and includes an update for the latest working draft of XInclude. This is the last release to support JDK 1.1. Added support for XML Catalogs. Implemented some remaining XML Schema errata and fixed several schema related bugs. Fixed various DOM Level 3 bugs. Implemented well-formedness checking for LSSerializer (DOM Level 3). Modified the XJavac task used by the build file so that Xerces can be built on Mac OS X with Apple JDK 1.4. Fixed possible security hole: the features and properties set on the parser were not propagated to the XMLSchemaLoader. Implemented the latest XInclude draft, excluding support for XPointer. Implemented missing support for supplemental characters in XML 1.1 names. Fixed a bug which caused the parser to overwrite some of the user's configuration with default values when namespace support was disabled. Implemented various performance improvements. Fixed various bugs. This release provides an implementation of W3C DOM Level 3 Core and Load/Save Candidate Recommendations and also brings Xerces into compliance with the most recent work of the W3C XML Core working group (XML 1.1, Namespace in XML 1.1, XML 1.0 3rd edition, XInclude). In addition, in this release we improved parser performance in several areas and fixed many bugs. Improved the scanning of attribute lists, both small and large. Reimplemented XML11Configuration (the default configuration), improving performance during reset; accomplished primarily by adding an internal feature which allows components to query whether or not they need to read features and properties from the configuration. Modified XML Schema interfaces (org.apache.xerces.xs) and updated the implementation accordingly. Methods were added to expose actual values and their types and new interfaces were added for loading XSModels. In addition, fixed various bugs in the implementation and PSVIWriter sample. Implemented the DOM Level 3 Core and Load and Save Candidate Recommendations. Added support for the 'well-formed' feature in DOM Level 3 Core. Added XML 1.1 support to DOM Level 3. Fixed the serializer so that TAB (0x9), LF (0xA), CR (0xD), NEL (0x85) and LSEP (0x2028) are escaped where appropriate in order to allow these characters to be roundtripped. Implemented experimental support for the XML 1.1 PR. This still excludes section 2.13. Fixed a bug which could cause the parser to run out of memory (or other resources) while parsing documents containing many entity references. Implemented missing support for Registry-based Naming Authority in the URI implementation. Modified the XJavac task used by the build file so that Xerces can be built on Linux with Blackdown JDK 1.4. Removed static references to sun.io.CharToByteConverter which made it impossible to compile Xerces on platforms that do not have this internal class. With binaries on such platforms, the serializer was unusable with many encodings. Added support for XML Base to the XInclude implementation. Fixed various bugs regarding text inclusion and relative URI resolution in the XInclude implementation. Implemented errata from the XML 1.0 Second Edition Specification. Moved Xerces' SAX support up to SAX 2.0.1. Fixed bugs in the XML 1.1 entity scanner that in some cases treated NEL (0x85) and LSEP (0x2028) as white space characters in internal entities, and not as end of line characters in external entities. Fixed bug in HTML DOM implementation that would cause a hierarchy request error by trying to move a doctype node to be a child of the <html> element. Fixed various bugs. This release provides a partial implementation of W3C XInclude specification as well as adds annotation support for the XML Schema component API. In addition to fixing many bugs, this release also brings Xerces into compliance with the most recent work of the W3C DOM working group on DOM level 3 Core and Load/Save, and includes additional fixes related to the XML 1.1 specification. Fixed an ArrayIndexOutOfBoundsException in the scanner caused by some invalid character references. Fixed various bugs related to XML 1.1. Fixed various bugs in the URI implementation, and added previously missing support for IPv6 addresses. Fixed performance issue for attributes with large value field. Implemented the latest DOM Level 3 Core and Load and Save drafts in Last Call. Added annotation support to the XML Schema component model API implementation. Modified the PSVI API to allow exposing facets as objects. Added preliminary XInclude implementation, excluding support for XPointer and XML Base specifications. Modified PSVIWriter to output all PSVI information. Changed it to output to an XNI event stream rather than a file. Modified error messages for Schema validation. Fixed various bugs. This release incorporates two minor changes to the Xerces Native Interface. In addition to fixing many bugs, this release also brings Xerces into compliance with the most recent work of the W3C DOM working group on DOM level 3 Core and Load/Save, and includes additional fixes based on the XML Schema errata. Also in this release, XML 1.1. is supported by default. Modified XNI XMLResourceIdentifier to include set/getNamespace. Added getEncoding method to the XNI XMLLocator interface. Fixed scanner implementation to be able to handle large CDATA sections without buffering. Made internal class loading strategy a bit more friendly in environments which need to provide classloaders to do things like manage multiple versions of Xerces. Improved robustness of build shell script under the Cygwin environment. Fixed null pointer exception in DTDConfiguration caused when no DTD handlers are registered. Fixed various bugs related to <redefine> in XML Schema traversal. Fixed various bugs related to the pattern facet (regular expression) in XML Schema. Implemented the latest DOM Level 3 Core and Load and Save drafts. Improved performance of XML11Configuration and made it the default configuration. Added support for ordering disconnected nodes (DOM Level 3 compareDocumentPosition) In anticipation of the DOM Level 3 Events specification, fix Xerces Events implementation to call event listeners in the order in which they were registered Implemented XML Schema errata as they were published. Fixed a bug related the external-schemaLocation property. Fixed various bugs. With this release, the Xerces-J developers are declaring the Xerces Native Interface (XNI) core and parsers packages to be gold. This release also brings Xerces into compliance with the most recent work of the W3C DOM working group on DOM level 3 Core and Load/Save, and introduces many fixes to bring Xerces's behaviour into line with XML Schema errata. Support for the parsing of documents written according to the XML 1.1 candidate recommendation has also been completed, except that no option for verifying that documents are normalized has yet been implemented. Finally, Xerces now provides means by which applications can force the parser to reject certain kinds of documents the processing of which could result in a denial-of-service attack. Modified XMLLocator interface to remove setter methods for move towards finalizing XNI; this change also implied removing XMLLocator's dependence upon XMLResourceIdentifier. Implemented several DOM Level 3 features, including DOMConfiguration, exposing type information via DOM, and allowing to set an ID attribute in the DOM. Modified support for DOM L3 compareDocumentPosition (formerly compareTreePosition). Modified several XNI interfaces, i.e. NamespaceContext, XMLResourceIdentifier, Augmentation, XMLAttributes, and updated implementation accordingly. Modified PSVI interfaces (org.apache.xerces.impl.xs.psvi) and updated implementation accordingly. Modified XMLDTDHandler, XMLDTDSource, XMLDTDContentModelHandler and XMLDTDContentModelSource to make these pipelines doubly-linked, as was done in the last release for the main document pipeline. Completed experimental support for XML 1.1 and XML Namespaces 1.1 CR's, except for XML 1.1 section 2.13. Provided a mechanism by which applications can instruct the parser to abort the parsing of documents containing constructs that could swamp system resources. Added a feature "disallow-doctype-decl" so that a fatal error is reported if this feature is on and the incoming document has a DOCTYPE. Added a feature "standard-uri-conformant" so that the parser enforces the URI rules when this feature is on. Performance update: ported the partial DTM implementation of DOM and use it for parsing Schema documents. Provided full support for canonical representation of XML Schema datatypes. Implemented XML Schema errata as they were published. Fix comment parsing bug that prevented Tomcat 4.1.12 from making use of Xerces versions later than 2.1.0. This release fixes four important bugs and several minor problems that were present in Xerces-J 2.2.0. Fixed SAX endElement call so that the element's namespace URI is returned. Fixed HTML DOM implementation so that it can be instantiated. Made the external-schema-location property work again. Enabled Xerces to validate the schema for schemas. As well as incorporating two changes to the Xerces Native Interface, this release focuses on performance improvements and bug fixes. Modified XMLComponent interface so that components used in a parser configuration can specify preferred default values for settings. Also updated all classes that implement the XMLComponent interface. Modified XNI XMLDocumentHandler interface so that NamespaceContext objects are passed on the startDocument call. This makes the start/endPrefixMapping calls redundant; they have been deprecated. Fixed many conformance bugs and enhanced the parser's performance in many situations. As well as some relatively minor changes to XNI, this release includes many bugfixes and performance improvements. Added xni.XMLDocumentHandler.setDocumentSource/getDocumentSource and XMLDocumentSource.getDocumentHandler methods to allow to modify Xerces pipeline dynamically. Store PSVI in DOM tree: when the new DOM document is used, element/attribute nodes can be casted to Element/AttributePSVI interfaces to retrieve PSVI properties. Provide access to PSVI via SAX using org.apache.xerces.impl.xs.psvi.PSVIProvider interface. Provided a way to convert preparsed schema grammars to XSModels. Message localization changes. Send all element PSVI properties on endElement calls, so that the application doesn't need to stack them when startElement is called. Made it possible to build a Schema Datatype jar file. Now it can be used as a standalone data type library. Performance update: avoid using exceptions to determine whether an array needs to be resized. Performance update: avoid adding the commonly used XML symbols to the symbol table again and again. Performance update: improve scanning speed by skipping end tag names and using proper input buffer size. Applied fixes to Xerces's regular expression support to address a number of bugs reported by users. Provide implementation for DOM Level 3 DOMBuilderFilter and DOMWriterFilter. Applied fixes to JAXP, SAX and internal object factory code so that it behaves correctly in environments where AccessControllers are being used. These fixes make it no longer possible to compile Xerces under JDK 1.1.8. Reorganize the code again to allow to build Xerces with DOM Level 3 support and modifying the build.xml to replace import statements in the source code. Changed various parts of Xerces's implementation so that it is now statically immutable. Reorganized identity constraint support to improve both conformance and performance. General bug fixes. In this release, numerous bugs have been fixed. Only one minor change in the Xerces Native Interface is included (documented below); considerable new functionality has also been added in terms of PSVI support, DOM level 3, and grammar preparsing/caching. Schema Component API interfaces and implementation; full PSVI support. Add XMLResourceIdentifier to startExternalSubset() method defined in XNI XMLDTDHandler. That allows supporting baseURI for an external subset. Add implementation for baseURI, documentURI, normalizeDocument and required normalize document features. Added support for DOM revalidation against XML Schemas. [DOM Level 3] Added implementation for compareTreePosition method of DOM L3. Added XMLGrammarLoader interface to the xni.grammars package; refactor DTD and Schema validation code to create classes implementing this interface; created a convenience class (XMLGrammarPreparser) that uses the new grammar loaders to permit grammar preparsing; wrote a sample (xni.XMLGrammarBuilder) that demonstrates how all this works. Reorganized the code in Xerces DOM implementation to expose DOM Level 3 functionality via org.w3c.dom package. Added several build targets for building customized xerces jar files that include DOM Level 3 Core and Load/Save interfaces and implementation of those interfaces: jars-dom3, apijar-dom3, sampjar-dom3. Updated xni.DocumentTracer sample to print augmentations for events. This makes it easier to debug configurations that augment the document's infoset. Removed dependence on SAX attribute interfaces from XMLAttributesImpl utility class. The AbstractSAXParser already defines a SAX attribute proxy class so that the parser and components can be properly layered. Moved from the org.xml.sax.helpers.AttributesImpl shipped with SAX 2.0 to that shipping in 2.0.1. This solves problems encountered with creating empty attribute lists. Improved handling of settings in parser classes making it easier to re-use the parsers with other parser configurations. Previously, the parser instances assumed that all configurations supported various settings (i.e. the parser would set default values without first adding the recognized features and property identifiers to the parser configuration). Fixed bug in HTML DOM implementation that was causing xerces.dom element nodes to be created instead of the appropriate HTML element nodes. Fixed bug to avoid null pointer exception in AbstractDOMParser when locator information is not available from parser configuration. Fixed bug in WrappedInput/OutputStream classes reported by Morten Bjørhus. The DTD validator failed to report "undeclared element" error if an attribute was declared for an undeclared element. Performance fixes: replaced code that increases array sizes by catching ArrayIndexOutOfBoundsExceptions with code that checks the sizes of the relevant arrays. Also streamlined several method calls in the DTD Grammar classes to account for the fact that scope is not relevant for this type of grammar. Finally, improved algorithm for recognizing entities and notations. Compress jars by default. We have not done so in the past, and it will be useful to see if this proves problematic or beneficial. Added several build targets for building customized xercesImpl jar files. Now we can build a DTD-only version, and a DTD-only version also excluding support for the HTML/WML DOM. Parser now reads external entities one chunk at a time, rather than a character at a time; this increases performance dramatically in certain circumstances. This fix also allows a number of EBCDIC encodings to work which did not work previously. Performance enhancement: implemented DOM node and declaration pools that reduce number of objects created during building of XML Schema grammars. Improved performance for non-deferred DOM: reduced number of concatenations for characters (bug #5602) According to the namespace spec errata, namespace declaration attributes should be bound to a special namespace; and errors should be reported on illegal bindings of "xmlns" and "xml" prefixes and their namespaces. Refined schema error messages: provide more descriptive error messages for simple type validation errors; avoid cascading errors when a grammar for a given namespace is not found, or when components from a certain namespace can't be accessed from a given schema document. Changed the lexical representation of gMonth from "--MM--" to "--MM". Decimal point shouldn't be allowed in integer-derived types; "fractionDigits" and "totalDigits" should be calculated on the value space. Fixed several DOM bugs. Xerces now passes W3C DOM Level 1 Core test suite. Improved management of ID attributes in the DOM so that Document.getElementByID is more reliable. Applied patch from Scott Sanders to fix Java serialization of the DOM and add a test. Applied patch from Henry Zongaro to fix a ClassCastException in the deferred DOM. Applied patch from Fabio Riccardi to reset normalize value in the PSVI. Applied patch from Joe Kesselman that fixes NPE in a NodeIterator (bug #6888). This release fixes a number of bugs. Fixed and closed bugs filed in Bugzilla. Added the support of reporting line/column numbers of schema errors. When creating DOM nodes, use Strings we already have, instead of creating new ones. Updated DTD datatypes to use the new datatype interfaces. Fixed an entity resolution bug: we passed null as the system ID to the entity resolver. Fixed a bug in the handling of URI's containing "../../". Fixed a thread-safety bug in schema simple type implementation. The implementation class should be stateless after construction. Fixed bugs in namespace algorithm for serialization. Fixed a bug in deferred DOM for CDATA nodes. Enabled processing of base 64-encoded material on OS/390. Modified XNI grammar interfaces such that Grammars now have an associated XMLGrammarDescription and XMLGrammarDescriptions record the type of the grammar. Fixed a bug related to Signature of call back attributeDecl in XNI samples. Fixed a bug related to feature prefix in AbstractDOMParser. Added the support for defer loading of schema grammars, grammar is parsed only when there is reference to any schema component from that namespace. JAXP 1.2 schemaSource property, if the String given is relative URI, now it is resolved against the instance document being parsed. Fixed a bug related to SchemaNormalizedValue to expose it only when validation attempted is full. This is the first production-quality release of the Xerces2 Java XML parser. We are confident that it also marks the stabilization of the XNI API, although changes in XNI are still possible. As well as these XNI improvements and extensions, a host of bugs and limitations that existed in Xerces 2.0.0beta4 have been fixed in this release. Implemented support for UCS-4 and UCS-2 encodings. Added ability to override default parser configuration. Implemented DOM Level 3 isEqualNode() method Implemented namespace fixup during serialization of DOM tree. Added implementation for new Xerces features validation/schema/normalized-value and validation/schema/element-default Implemented current-element-node property Added internal subset string to DOM. Added support for warn-on-duplicate-attdef xerces feature validation/warn-on-duplicate-attdef Added an interface, XMLResourceIdentifier, for describing the physical location of XML resources (external entities, schemas etc.) for use in grammar caching and entity resolution. Updated XMLEntityResolver, XMLLocator, XMLDocumentHandler, XMLDocumentFragmentHandler, and XMLDTDHandler to use this new interface consistently instead of unwieldy lists of Strings in various callbacks. Updated Xerces Native Interface to add augmentations to document fragment handler, DTD handler, and the DTD content model handler interfaces. Additional methods were also renamed and/or modified. Updated Xerces Native Interface to add methods to Augmentations, XMLAttributes, and modify PSVI interfaces. Cleaned up separation between DOMParser and DeferredDOM by moving part of the code from createDeferredElement back into the parser, this has several benefits including to only have to walk the list of attributes once Provided support for fundamental facets in DV implementation Moved schema simple type error messages to the property file to enable localization. Fixed various bugs related to the dependency between schema documents. Modified URI resolution strategy so that Windows network paths are recognized. Fixed various bugs related to schema components traversal and validation. Fixed a bug in the ui.DOMParserSaveEncoding sample. Modified XMLDTDScanner to synchronize start/end entity calls. Fixed XMLDocumentScannerImpl so it always checks settings for load-external-dtd feature. Modified implementation of setDocumentHandler(): now user can change document handler during the parse. Fixed DOM L2 bugs: synchronization for entity reference nodes, cloning of attribute node, report of event phases. Fixed a bug in XMLDocumentFragmentScannerImpl occurring when a ] is encountered at the end of an entity. Fixed misc. SAX bugs. Fixed JAXP implementation of schemaLanguage property. Massive Javadoc fixes. Fixed external-schemaLocation and external-noNamespaceSchemalocation properties related bug (# 5768) Fixed namespaces and namespace-prefixes related SAX bug. Corrected features documentation for string-interning feature. Fixed the bug in which duplicate attribute definitions were not ignored and error was reported for ID datatype and Notation. Fixed the bug where 'locale' value was not set for StandardParserConfiguration. This release fixes a number of bugs, introduces more changes to the Xerces Native Interface, provides partial experimental DOM Level 3 implementation, and includes full XML Schema support. Implemented schema particle derivation restriction checking Added checking for schema constraint cos-element-consistent resolved misc. SAX2 bugs Added implementation of DOMInputSource, DOMError, DOMLocator and wrappers for entity resolver and error handler (DOM Level 3). Added implementation of DOMWriter, DocumentLS, DOMImplementationLS and new features support for save and load: create-cdata-nodes, split-cdata-sections (DOM Level 3). Added implementation of DOMBuilder, DOMASBuilder and partial implementation of ASModel. Add support for a new feature "include-comments" (DOM Level 3). Added Augmentations interface to core XNI interfaces and PSVI interfaces as an extension to XNI (unstable). Added DOM Level 3 interfaces to xerces.dom3 package. Modified samples accordingly. Implemented split of xerces.jar file into an API-only jar file (xmlParserAPIs.jar) and a jar file containing only the API implementation (xercesImpl.jar). Modified XNI document handler interface to include Augmentations as an extra parameter on each parser event. Modified XMLAttributes interface to include getter methods for augmentations. Implemented PSVI support in Xerces and added PSVIWriter, PSVIParser and PSVIConfiguration sample files. Added "external-schemaLocation" and "external-noNamespaceSchemaLocation" properties. New schema simple type interface and implementation. It fixes various bugs in the old implementation, and provides enough information for PSVI support. Internalize all symbols in SymbolTable using java.lang.String#intern(). Now applications can compare the symbols by reference. Added "schema-full-checking" feature, and implemented "Unique Particle Attribution" constraint. Changed the default configuration to standard parser configuration (that does not include XML Schema validator), modified how and when the pipeline is constructed. Changed XML Schema validation behavior back to validate only if the http://xml.org/sax/features/validation feature is true. Note: XML Schema validation is off by default. Added constructor to new DTDXSParserConfiguration so it can share settings from a parent configuration. The parser no longer wraps RuntimeException with XNIException in the parse method. Fixed cloneNode() for Entity, EntityReference and DocumentType. Fixed importNode() of EntityReference nodes which mistakenly carried the old value. Fixed handling EntityReference node subtrees that left the node empty in non deferred DOM. Added missing default attribute values in the DOM and fixed double entity value bug in deferred DOM. Fixed getElementById() in the DOMParser. Bound namespace attributes to http://www.w3.org/2000/xmlns/ (DOM only). Various documentation fixes. Added more DOM Level 3 interfaces to xerces.dom3 package. Implemented DOMImplementationRegistry (DOMImplementationSource really), Node.set/getTextContent(), Node.isSameNode(), Node.getInterface(), Node.set/getUserData(). Extended dom.mem.Test to test these additions. Added ASBuilder sample to the DOM samples package to show how to use the new DOM level 3 ASBuilder interface to implement a form of grammar caching. Enabled the parser to process documents encoded in EBCDIC and UTF-16. This release fixes a number of bugs, introduces some changes to the Xerces Native Interface, and is the first Xerces2 release to include XML Schema validation support. Please note that the XML Schema validation code was completely rewritten for Xerces2 and should be considered alpha at this time. Redesigned and rewrote XML Schema validation code. Also updated standard parser configuration to include the XML Schema validator in the document pipeline by default. Added new default parser configuration that includes DTD and XML Schema validators (DTDXSParserConfiguration). Implemented dynamic validation for both validators. Synched up javax.xml.parsers package with latest code from xml-commons module and various bug fixes. DOM/ DOMParser bug fixes. Fixed newline normalization bug. Previously, the sequence #x0A #x0D was being converted to #x0A instead of #x0A #x0A per section 2.11 of the XML 1.0 specification. Thanks to Aleksander Slominski for the bug report. Added getter methods to XMLParserConfiguration interface and added filter interfaces for components that consume and produce document and DTD information. Fixed DTD scanner from reporting entity boundaries appearing inside of markup declarations. Entity boundaries appearing in the content model of an element declaration is still reported, though. Simplified XMLAttributes interface by removing the methods related to entities appearing in attribute values. Changed the XMLDTDHandler defined in XNI to add a non-normalized value parameter to the internal element declaration callback. Also implemented the non-normalized value for attribute values. Fixed bug in entity manager that would never resolve IANA encoding names to Java encoding names properly. (Bug #3449) Fixed bug in SAX parser that was not forwarding external entity declarations in the DTD. (Bug #3392) Separated the XMLDocumentScannerImpl class so that it derives from XMLDocumentFragmentScannerImpl which enables an application to parse document fragments. Ported the deferred DOM implementation from the Xerces 1.x codebase. This is primarily a bug fix release. However, a new XNI interface and additional documentation have been added. Fixed bug for when namespace bindings were added as default attributes from the DTD. Fixed Xerces2 standard components to properly recognize and use the features and properties that they are documented to accept. Added documentation to the XNI Manual for re-using the Xerces2 parser components. Moved Xerces 1.x to "xerces_j_1" branch and moved Xerces2 to the main trunk of the "xml-xerces" module. Improved ability of document and DTD scanners to perform pull parsing. Fixed bug where namespace binder would turn an emptyElement callback into startElement and endElement callbacks. Updated standard parser configuration to separate DTD validation and namespace binding in the parsing pipeline. Removed old XML Schema code that was not being used. This code is intended to be replaced by either a port of the Xerces 1.x XML Schema implementation or by a re-designed, re-implemented XML Schema implementation. Fixed bug in scanner that allowed the built-in entity references to be sent via XNI. The default value for this feature should have been false. Fixed several SAX bugs. Synchronized DOM implementation code from Xerces 1.x codebase. First beta release of the Xerces2 code. Besides numerous bug fixes, this release has changes and additions to XNI. The new XNI parser configuration framework has been added in this release. Refer to the XNI Manual for complete information. Added document and DTD scanner interfaces to XNI to allow parser configuration pipelines to be constructed generically. Fixed bug in DTD grammar for mixed content models that was building the wrong validation content model. Removed SAX dependency from XNI framework. Now the only dependence on external API such as SAX is in the implementation of the AbstractSAXParser and DOMParser so that legacy code doesn't break. Rewrote existing documentation, added XNI information, cleaned up stylesheets, and converted some docs to use custom DTDs. DTD method ordering problem for INCLUDE/IGNORE sections. Improved DFA build-time performance. Synchronized with Xerces 1.3.0 Initial alpha release of Xerces2 code. xerces-2_11_0/docs/samples-dom.xml100644 0 0 33302 11474015642 14275 0ustar 0 0

This page documents the various Document Object Model (DOM) samples included with Xerces. Besides being useful programs, they can be used as DOM programming examples to learn how to program using the DOM API.

Basic DOM samples:

Most of the DOM parser samples have a command line option that allows the user to specify a different DOM parser to use. In order to supply another DOM parser besides the default Xerces DOMParser, a DOM parser wrapper class must be written. This class must implement the dom.ParserWrapper interface.

JAXP could be used instead of the special DOM parser wrapper class. However, that feature is not implemented at this time. Using JAXP would require the user to specify the -Djavax.xml.parsers.DocumentBuilderFactory=... option to the virtual machine in order to use a different document builder factory.

A sample DOM counter. This sample program illustrates how to traverse a DOM tree in order to get information about the document. The output of this program shows the time and count of elements, attributes, ignorable whitespaces, and characters appearing in the document. Three times are shown: the parse time, the first traversal of the document, and the second traversal of the tree.

This class is useful as a "poor-man's" performance tester to compare the speed and accuracy of various DOM parsers. However, it is important to note that the first parse time of a parser will include both VM class load time and parser initialization that would not be present in subsequent parses with the same file.

The results produced by this program should never be accepted as true performance measurements. java dom.Counter (options) uri ...
OptionDescription
-p nameSelect parser wrapper by name.
-x numberSelect number of repetitions.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-hDisplay help screen.

A sample DOM filter. This sample program illustrates how to use the Document#getElementsByTagName() method to quickly and easily locate elements by name.

java dom.GetElementsByTagName (options) uri ...
OptionDescription
-p nameSelect parser wrapper by name.
-e nameSpecify element name for search.
-a nameSpecify attribute name for specified elements.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-hDisplay help screen.

A sample DOM writer. This sample program illustrates how to traverse a DOM tree in order to print a document that is parsed.

java dom.Writer (options) uri ...
-p nameSelect parser wrapper by name.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-xd | -XD Turn on/off loading of external DTDs.
NOTE: Always on when -v in use and not supported by all parsers.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-ga | -GA Turn on/off generation of synthetic schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-c | -C Turn on/off Canonical XML output.
NOTE: This is not W3C canonical output.
-hDisplay help screen.

This sample program illustrates how to use the org.w3c.dom.ElementTraversal API.

java dom.ElementPrinter uri

This sample program illustrates how to use the DOM Level 3 API.

java dom.DOM3 uri

A sample of Adding lines to the DOM Node. This sample program illustrates:

  • How to override methods from DocumentHandler ( XMLDocumentHandler)
  • How to turn off ignorable white spaces by overriding ignorableWhiteSpace
  • How to use the SAX Locator to return row position (line number of DOM element)
  • How to attach user defined Objects to Nodes using the DOM Level 3 setUserData method.
java dom.DOMAddLines (options) uri ...
OptionDescription
-hDisplay help screen.
-iDon't print ignorable white spaces.
 xerces-2_11_0/docs/samples-jaxp.xml100644 0 0 25105 11474015642 14462 0ustar 0 0

This page documents the various Java API for XML Processing (JAXP) samples included with Xerces. Besides being useful programs, they can be used as JAXP programming examples to learn how to program using the JAXP API.

JAXP samples:

A sample which demonstrates usage of classes in the javax.xml.parsers package, particularly new features introduced in JAXP 1.3 and 1.4, including XInclude processing, integration with the JAXP 1.4 Validation API and parser reset.

java jaxp.ParserAPIUsage (options) uri
OptionDescription
-a uri ...Provide a list of schema documents.
-api (sax|dom)Select API to use (sax|dom).
-xi | -XITurn on/off XInclude processing.
-sp | -SPTurn on/off secure processing.
-hDisplay help screen.

A sample demonstrating how to use the JAXP 1.4 Validation API to create a validator and use the validator to validate input from SAX, DOM or a stream. The output of this program shows the time spent executing the Validator.validate(Source) method.

This class is useful as a "poor-man's" performance tester to compare the speed of various JAXP 1.4 validators with different input sources. However, it is important to note that the first validation time of a validator will include both VM class load time and validator initialization that would not be present in subsequent validations with the same document. Also note that when the source for validation is SAX or a stream, the validation time will also include the time to parse the document, whereas the DOM validation is completely in memory.

The results produced by this program should never be accepted as true performance measurements. java jaxp.SourceValidator (options) ...
OptionDescription
-l nameSelect schema language by name.
-x numberSelect number of repetitions.
-a uri ...Provide a list of schema documents.
-i uri ...Provide a list of instance documents to validate.
-vs sourceSelect validation source (sax|dom|stax|stream).
-f | -F Turn on/off Schema full checking.
NOTE: Not supported by all schema factories and validators.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Not supported by all schema factories and validators.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Not supported by all schema factories and validators.
-ga | -GA Turn on/off generation of synthetic schema annotations.
NOTE: Not supported by all schema factories and validators.
-m | -MTurn on/off memory usage report.
-hDisplay help screen.

The speed and memory results from this program should NOT be used as the basis of parser performance comparison! Real analytical methods should be used. For better results, perform multiple validations within the same virtual machine to remove class loading from parse time and memory usage.

Not all features are supported by different parsers.

A sample demonstrating how to use the JAXP 1.4 Validation API to create a validator and use the validator to validate input from a DOM which contains inline schemas and multiple validation roots. The output of this program shows the time spent executing the Validator.validate(Source) method.

This class is useful as a "poor-man's" performance tester to compare the speed of various JAXP 1.4 validators with different input sources. However, it is important to note that the first validation time of a validator will include both VM class load time and validator initialization that would not be present in subsequent validations with the same document.

This sample makes use of the JAXP 1.3 XPath API and requires either a JAXP 1.3 compliant XSLT processor (or JDK 5.0) to run. The results produced by this program should never be accepted as true performance measurements. java jaxp.InlineSchemaValidator (options) uri ...
OptionDescription
-l nameSelect schema language by name.
-x numberSelect number of repetitions.
-a xpath ...Provide a list of XPath expressions for schema roots.
-i xpath ...Provide a list of XPath expressions for validation roots.
-nm pre uri ...Provide a list of prefix to namespace URI mappings for the XPath expressions.
-f | -F Turn on/off Schema full checking.
NOTE: Not supported by all schema factories and validators.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Not supported by all schema factories and validators.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Not supported by all schema factories and validators.
-ga | -GA Turn on/off generation of synthetic schema annotations.
NOTE: Not supported by all schema factories and validators.
-m | -MTurn on/off memory usage report.
-hDisplay help screen.

The speed and memory results from this program should NOT be used as the basis of parser performance comparison! Real analytical methods should be used. For better results, perform multiple validations within the same virtual machine to remove class loading from parse time and memory usage.

Not all features are supported by different parsers.

Provides a trace of the schema type information for elements and attributes in an XML document. This demonstrates usage of the JAXP 1.4 Validation API, particuarly how to read type information from a TypeInfoProvider.

java jaxp.TypeInfoWriter (options) ...
OptionDescription
-l nameSelect schema language by name.
-p nameSelect parser by name.
-a uri ...Provide a list of schema documents.
-i uri ...Provide a list of instance documents to validate.
-f | -F Turn on/off Schema full checking.
NOTE: Not supported by all schema factories and validators.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Not supported by all schema factories and validators.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Not supported by all schema factories and validators.
-ga | -GA Turn on/off generation of synthetic schema annotations.
NOTE: Not supported by all schema factories and validators.
-hDisplay help screen.

A sample which demonstrates usage of the JAXP 1.3 Datatype API.

java jaxp.DatatypeAPIUsage xerces-2_11_0/docs/samples-sax.xml100644 0 0 27717 11474015642 14326 0ustar 0 0

This page documents the various Simple API for XML (SAX) samples included with Xerces. Besides being useful programs, they can be used as SAX programming examples to learn how to program using the SAX API.

SAX samples:

Most of the SAX parser samples have a command line option that allows the user to specify a different parser to use. In order to supply another SAX parser besides the default Xerces SAXParser, the parser must implement either the org.xml.sax.Parser or org.xml.sax.XMLReader interfaces. You may specify xni.parser.PSVIParser if you want Xerces to output PSVI.

JAXP could be used instead but this feature is not implemented at this time. Using JAXP would require the user to specify the -Djavax.xml.parsers.SAXParserFactory=... option to the virtual machine in order to use a different SAX parser factory.

A sample SAX2 counter. This sample program illustrates how to register a SAX2 ContentHandler and receive the callbacks in order to print information about the document. The output of this program shows the time and count of elements, attributes, ignorable whitespaces, and characters appearing in the document.

This class is useful as a "poor-man's" performance tester to compare the speed and accuracy of various SAX parsers. However, it is important to note that the first parse time of a parser will include both VM class load time and parser initialization that would not be present in subsequent parses with the same file.

The results produced by this program should never be accepted as true performance measurements. java sax.Counter (options) uri ...
OptionDescription
-p nameSelect parser by name.
-x numberSelect number of repetitions.
-n | -NTurn on/off namespace processing.
-np | -NP Turn on/off namespace prefixes.
NOTE: Requires use of -n.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-m | -MTurn on/off memory usage report.
-t | -TTurn on/off \"tagginess\" report.
--rem text Output user defined comment before next parse.
-hDisplay help screen.

The speed and memory results from this program should NOT be used as the basis of parser performance comparison! Real analytical methods should be used. For better results, perform multiple document parses within the same virtual machine to remove class loading from parse time and memory usage.

The "tagginess" measurement gives a rough estimate of the percentage of markup versus content in the XML document. The percent tagginess of a document is equal to the minimum amount of tag characters required for elements, attributes, and processing instructions divided by the total amount of characters (characters, ignorable whitespace, and tag characters) in the document.

Not all features are supported by different parsers.

Provides a complete trace of SAX2 events for files parsed. This is useful for making sure that a SAX parser implementation faithfully communicates all information in the document to the SAX handlers.

java sax.DocumentTracer (options) uri ...
OptionDescription
-p nameSelect parser by name.
-n | -NTurn on/off namespace processing.
-np | -NP Turn on/off namespace prefixes.
NOTE: Requires use of -n.
-v | -VTurn on/off validation.
-xd | -XD Turn on/off loading of external DTDs.
NOTE: Always on when -v in use and not supported by all parsers.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-hDisplay help screen.

A sample SAX2 writer. This sample program illustrates how to register a SAX2 ContentHandler and receive the callbacks in order to print a document that is parsed.

java sax.Writer (options) uri ...
OptionDescription
-p nameSelect parser by name.
-n | -NTurn on/off namespace processing.
-np | -NP Turn on/off namespace prefixes.
NOTE: Requires use of -n.
-v | -VTurn on/off validation.
-xd | -XD Turn on/off loading of external DTDs.
NOTE: Always on when -v in use and not supported by all parsers.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-va | -VA Turn on/off validation of schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-ga | -GA Turn on/off generation of synthetic schema annotations.
NOTE: Requires use of -s and not supported by all parsers.
-dv | -DV Turn on/off dynamic validation.
NOTE: Not supported by all parsers.
-xi | -XI Turn on/off XInclude processing.
NOTE: Not supported by all parsers.
-xb | -XB Turn on/off base URI fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-xl | -XL Turn on/off language fixup during XInclude processing.
NOTE: Requires use of -xi and not supported by all parsers.
-c | -C Turn on/off Canonical XML output.
NOTE: This is not W3C canonical output.
-hDisplay help screen.
 xerces-2_11_0/docs/samples-socket.xml100644 0 0 13326 11474015641 15011 0ustar 0 0

Very often, applications need to transmit XML documents over the network using a socket stream. However, XML is not designed to make this possible because XML documents do not contain an explicit end-of-document terminal. Therefore, the stream must end (i.e. the socket must close) in order for the parser to finish parsing the complete XML document.

Since creating socket streams is expensive the application needs to re-use the same stream but XML doesn't define an end-of-document. Therefore, another solution must be found. The socket samples included with Xerces can be used to learn how to overcome this common problem in a general way.

Socket samples:

This sample delays the input to the SAX parser to simulate reading data from a socket where data is not always immediately available. An XML parser should be able to parse the input and perform the necessary callbacks as data becomes available. So this is a good way to test any parser that implements the SAX2 XMLReader interface to see if it can parse data as it arrives.

Note: This sample uses NSGMLS-like output of elements and attributes interspersed with information about how many bytes are being read at a time.

java socket.DelayedInput (options) filename ...
OptionDescription
-p nameSelect SAX2 parser by name.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parsers.");
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hDisplay help screen.

This sample provides a solution to the problem of 1) sending multiple XML documents over a single socket connection or 2) sending other types of data after the XML document without closing the socket connection.

The first situation is a problem because the XML specification does not allow a document to contain multiple root elements. Therefore a document stream must end (or at least appear to end) for the XML parser to accept it as the end of the document.

The second situation is a problem because the XML parser buffers the input stream in specified block sizes for performance reasons. This could cause the parser to accidentally read additional bytes of data beyond the end of the document. This actually relates to the first problem if the documents are encoding in two different international encodings.

The solution that this sample introduces wraps both the input and output stream on both ends of the socket. The stream wrappers introduce a protocol that allows arbitrary length data to be sent as separate, localized input streams. While the socket stream remains open, a separate input stream is created to "wrap" an incoming document and make it appear as if it were a standalone input stream.

To use this sample, enter any number of filenames of XML documents as parameters to the program. For example:

java socket.KeepSocketOpen doc1.xml doc2.xml doc3.xml

This program will create a server and client thread that communicate on a specified port number on the "localhost" address. When the client connects to the server, the server sends each XML document specified on the command line to the client in sequence, wrapping each document in a WrappedOutputStream. The client uses a WrappedInputStream to read the data and pass it to the parser.

Do not send any XML documents with associated grammars to the client. In other words, don't send any documents that contain a DOCTYPE line that references an external DTD because the client will not be able to resolve the location of the DTD and an error will be issued by the client. xerces-2_11_0/docs/samples-ui.xml100644 0 0 2633 11474015642 14116 0ustar 0 0

TODO

 xerces-2_11_0/docs/samples-xni.xml100644 0 0 50027 11474015642 14317 0ustar 0 0

The Xerces Native Interface (XNI) is an internal API that is independent of other XML APIs and is used to implement the Xerces family of parsers. XNI allows a wide variety of parsers to be written in an easy and modular fashion. The XNI samples included with Xerces are simple examples of how to program using the XNI API. However, for information on how to take full advantage of this powerful framework, refer to the XNI Manual.

Basic XNI samples:

Parser configuration samples:

Sample xerces.properties

Most of the XNI samples have a command line option that allows the user to specify a different XNI parser configuration to use. In order to supply another parser configuration besides the default Xerces &DefaultConfig;, the configuration must implement the org.apache.xerces.xni.parser.XMLParserConfiguration interface.

A sample XNI counter. The output of this program shows the time and count of elements, attributes, ignorable whitespaces, and characters appearing in the document.

This class is useful as a "poor-man's" performance tester to compare the speed and accuracy of various parser configurations. However, it is important to note that the first parse time of a parser will include both VM class load time and parser initialization that would not be present in subsequent parses with the same file.

The results produced by this program should never be accepted as true performance measurements. java xni.Counter (options) uri ...
OptionDescription
-p nameSelect parser configuration by name.
-x numberSelect number of repetitions.
-n | -NTurn on/off namespace processing.
-np | -NP Turn on/off namespace prefixes.
NOTE: Requires use of -n.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parser configurations.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-m | -MTurn on/off memory usage report.
-t | -TTurn on/off \"tagginess\" report.
--rem text Output user defined comment before next parse.
-hDisplay help screen.

The speed and memory results from this program should NOT be used as the basis of parser performance comparison! Real analytical methods should be used. For better results, perform multiple document parses within the same virtual machine to remove class loading from parse time and memory usage.

The "tagginess" measurement gives a rough estimate of the percentage of markup versus content in the XML document. The percent tagginess of a document is equal to the minimum amount of tag characters required for elements, attributes, and processing instructions divided by the total amount of characters (characters, ignorable whitespace, and tag characters) in the document.

Not all features are supported by different parser configurations.

Provides a complete trace of XNI document and DTD events for files parsed.

java xni.DocumentTracer (options) uri ...
OptionDescription
-p nameSpecify parser configuration by name.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parser configurations.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-c | -CTurn on/off character notifications
-hDisplay help screen.

A sample XNI writer. This sample program illustrates how to take received XMLDocumentHandler callbacks in order to print a document that is parsed.

java xni.Writer (options) uri ...
OptionDescription
-p nameSelect parser configuration by name.
-n | -NTurn on/off namespace processing.
-v | -VTurn on/off validation.
-s | -S Turn on/off Schema validation support.
NOTE: Not supported by all parser configurations.
-f | -F Turn on/off Schema full checking.
NOTE: Requires use of -s and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -s and not supported by all parsers.
-hDisplay help screen.

This is an example of a component that converts XNI events for a document into XNI events for that document's PSVI information.

This class can NOT be run as a standalone program. It is only an example of how to write a component. See xni.parser.PSVIConfiguration and xni.parser.PSVIParser.

This sample illustrates how to use Xerces' grammar preparsing functionality to build a compiled representation of a grammar and use it to parse instance documents. It is also meant to replace the DOM ASBuilder sample (which implements the DOM AS interfaces which have been discontinued by W3C). It handles both XML Schema grammars and DTD external subsets.

java xni.XMLGrammarBuilder [-p name] -d uri ... | [-f|-F] [-hs|-HS] -a uri ... [-i uri ...]
OptionDescription
-p nameSelect parser configuration by name to use for instance validation.
-dURI of file(s) to be compiled as DTD external subsets
-aURI of file(s) to be compiled as XML Schema grammars
-f | -F Turn on/off Schema full checking when validating instances against schemas.
NOTE: Requires use of -a and not supported by all parsers.
-hs | -HS Turn on/off honouring of all schema locations.
NOTE: Requires use of -a and not supported by all parsers.
-iList of instance documents to validate. The preparsed grammars will be used first, but if a reference is made to a non-preparsed grammar, it will be resolved.

No two schema grammars preparsed by this class should share the same targetNamespace (or have no targetNamespace). If this condition is not meant, results are undefined--but, very likely, one of the schemas will simply be ignored.

Not all features are supported by different parser configurations. Particularly, if a parser configuration is specified, it would be wise to ensure it supports the kind of grammars to be preparsed.

This sample demonstrates how to implement a simple pass-through filter for the document "streaming" information set using XNI. This filter could be used in a pipeline of XNI parser components that communicate document events.

This class can NOT be run as a standalone program. It is only an example of how to write a document handler.

This sample demonstrates how to create a filter for the document "streaming" information set that turns element names into upper case.

This class can NOT be run as a standalone program. It is only an example of how to write a document handler.

Non-validating parser configuration.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option. For example:

java xni.Counter -p xni.parser.NonValidatingParserConfiguration document.xml

This abstract parser configuration simply helps manage components, features and properties, and other tasks common to all parser configurations. In order to subclass this configuration and use it effectively, the subclass is required to do the following:

  • Add all configurable components using the addComponent method,
  • Implement the parse method, and
  • Call the resetComponents before parsing.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI.

This example is a very simple parser configuration that can parse files with comma-separated values (CSV) to generate XML events. For example, the following CSV document:

Andy Clark,16 Jan 1973,Cincinnati

produces the following XML "document" as represented by the XNI streaming document information:

]> Andy Clark 16 Jan 1973 Cincinnati ]]>

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option. For example:

java xni.Counter -p xni.parser.CSVConfiguration document.xml

This parser class implements a SAX parser that can parse simple comma-separated value (CSV) files.

This class can NOT be run as a standalone program. It is only an example of how to write a parser using XNI. You can use this parser by specifying the fully qualified class name to all of the SAX samples that accept a parser using the -p option. For example:

java sax.Counter -p xni.parser.CSVParser document.xml

This example is a parser configuration that can includes a post schema validation infoset converter. The configuration includes: DTD validator, Namespace binder, XML Schema validators and PSVIWriter component.

This class can NOT be run as a standalone program. It is only an example of how to write a parser configuration using XNI. You can use this parser configuration by specifying the fully qualified class name to all of the XNI samples that accept a parser configuration using the -p option:

java xni.Writer -v -s -p xni.parser.PSVIConfiguration personal-schema.xml Validation and schema validation features must be set to true to receive the correct PSVI output.

This parser class implements a SAX parser that outputs events for the post schema validation infoset of a document.

This class can NOT be run as a standalone program. It is only an example of how to write a parser using XNI. You can use this parser by specifying the fully qualified class name to all of the SAX samples that accept a parser using the -p option. For example:

java sax.Writer -v -s -p xni.parser.PSVIParser personal-schema.xml Validation and schema validation features must be set to true to receive the correct PSVI output.

When you create a Xerces parser, either directly using a native class like org.apache.xerces.parsers.DOMParser, or via a standard API like JAXP, Xerces provides a dynamic means of dynamically selecting a "configuration" for that parser. Configurations are the basic mechanism Xerces uses to decide exactly how it will treat an XML document (e.g., whether it needs to know about Schema validation, whether it needs to be cognizant of potential denial-of-service attacks launched via malicious XML documents, etc.) The steps are fourfold:

  1. * first, Xerces will examine the system property org.apache.xerces.xni.parser.XMLParserConfiguration;
  2. next, it will try and find a file called xerces.properties in the lib subdirectory of your JRE installation;
  3. next, it will examine all the jars on your classpath to try and find one with the appropriate entry in its META-INF/services directory.
  4. if all else fails, it will use a hardcoded default.

The third step can be quite time-consuming, especially if you have a lot of jars on your classpath and run applications which require the creation of lots of parsers. If you know you're only using applications which require "standard" APIs (that is, don't need some special Xerces property), or you want to try and force applications to use only certain Xerces configurations, then you may wish to copy this file into your JRE's lib directory. We try and ensure that this file contains the currently-recommended default configuration; if you know which configuration you want, you may substitute that class name for what we've provided here.

 xerces-2_11_0/docs/samples.xml100644 0 0 5701 11474015641 13501 0ustar 0 0

&ParserName; contains many useful samples to help you get up-and-running with writing XML applications. Many of the sample programs are even useful as standalone programs to help in testing the validity of XML documents and/or debugging applications.

The samples are organized either by API or by programming area in the following categories:

Running the sample applications requires that you have already installed the Java Development Kit (JDK) or Java Runtime Environment (JRE) on your computer and extracted the &ParserName; software.

If you do not already have a JDK already on your computer download one from Sun's Java website: http://java.sun.com or from IBM's website http://www.ibm.com/developer/java/. The sample applications described in the following pages support Java 1.x (e.g. 1.1.8, etc) and/or Java 2 (e.g. 1.2.2, 1.3, etc). The UI samples are written using Swing and require Java 2 in order to run but all of the command line programs will run using Java 1.x.

Command lines examples on the following pages use the Windows path separator ';' (semicolon) and directory separator '\' (backslash). On UNIX, use the ':' (colon) character to separate the JAR files in the classpath, and replace Windows directory separator '\' (backslash) with '/' (forward slash).

xerces-2_11_0/docs/sax.xml100644 0 0 3342 11474015642 12630 0ustar 0 0

Xerces2 provides an implementation of SAX 2.0.2 and SAX2 Extensions 1.1.

SAX 1.0 and SAX 2.0 information:

This section provides the following topics:

 xerces-2_11_0/docs/source-repository.xml100644 0 0 5346 11474015642 15560 0ustar 0 0

The &ParserNameLong; source code is stored in the Subversion repository (SVN). The SVN repository is public and everyone has read access. The repository uses a standard layout of:

https://svn.apache.org/repos/asf/xerces/java/ | | - branches/ | | - tags/ \ - trunk/

For example, to check out the trunk (the place where the main development is taking place), execute:

svn co https://svn.apache.org/repos/asf/xerces/java/trunk

To check out the code in the stax-dev branch, execute:

svn co https://svn.apache.org/repos/asf/xerces/java/branches/stax-dev

To check out the code tagged Xerces-J_2_6_2, execute:

svn co https://svn.apache.org/repos/asf/xerces/java/tags/Xerces-J_2_6_2

You can also browse the repository and examine individual files using the Web interface.

 xerces-2_11_0/docs/style/graphics/button-a.gif100644 0 0 263 11474015642 16452 0ustar 0 0 GIF89ax ³™xx­ŒŒ­¬Á¤¤Ò¬ŸŸyppxooe]]d\\!ù,x @`°˜@«½8ëÍ»ÿ`‡(Ò`žhª®lë¾p,»Â‘”'¡Ï|ïÿ@ÔH*Ȥˆd@@pJ­öj·¦uËí²°D¥xL.µÞ´ºzv>¥ë¸œÕFEáó¼ŒÖûõ|‚yX;xerces-2_11_0/docs/style/graphics/button-b.gif100644 0 0 232 11474015642 16447 0ustar 0 0 GIF89ax ³×××±±±–––•••~~~}}}jjjiii,x O„A«½8ëÍ»ÿ`WRhžhªŠä´¾p,¥lßøF»TàçÀ`jgù„Ȥ®UŽÊ¨R@0Ô*O¨t ¤ZyÜ0Ò{›sdðyK³ßíj;xerces-2_11_0/docs/style/loader.xml100644 0 0 407 11474015642 14422 0ustar 0 0 xerces-2_11_0/docs/style/resources/bottom.gif100644 0 0 2063 11474015642 16457 0ustar 0 0 GIF89a¨÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,¨ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜȱ£ÇÁˆI²¤É“(Sª\ɲ¥Ë—0c¶襦͛8sêÜɳ§ÏŸ@ƒ J(/ “*]š)O¡D µªT«T¯jÍʫ׭_»‚+¶lسdÑŠ=J³-Û·HáºKw®]¹xë潫·/ß¿{û x0ÓÈ?tª¶qÚÇf!;ŽLy²eɘ£Þ<¸sáÏœA{Mz´é»ŠS«VÍ8óåÊ®cÞýº¶ì§K‹Þ­»wîß¼ã]M¼xÓÛÈi'·­¼9sǾƒKN]¸õé¹kߎ±¨÷ïàË>†ùóèÓ«_Ͼ½û÷ðãËŸO¿þü€;xerces-2_11_0/docs/style/resources/button-asf-hi.gif100644 0 0 2777 11474015642 17647 0ustar 0 0 GIF89a`÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éέ”R¾ ,: Ø6Güºr%êHıöˆ ¦a“ œyEl,=PÞüêÅJ™KÉ–ùªó*=Âô"F[ÔÀ2Ÿ¨U“Eç‹­#Ä‚‚RÇj¯òL+pÈ5KÀù9µLŽ6L…Àƒ£mÔ#p{†€ÿÓ¤\Ÿi¤s\fF"¢=®Ñ|T†L’–«Ì p€8N&ü1$"RM4jT³‹‚»¤Œ1‡üŠr1Å#"8B¥Dà ¹È2J5ÙT²"q€ÃÉ/ÉIJ 2i 4H5Ÿhš1®Üá ¶ìRDP ¡M¦ý"‚/ÄtãG#àø²‹#Á¢„@¥€cÇ4¹,B *x€óHŠ‚a]É E ’Œ6öq¢Í1Ÿü¢D5p@ñ‹1G<‚ 5C„Š6¢€ Áˆ°D.zıM.¶€C‡+Ú¨!ÐÁHC‰)NB© $x ôŠ1¢eÉP°Œa:‚È0ڜ乗@_üb¨!àt#ÐG‡©µô 8E¨A8”@qÉ)n$CÌ-Ç ÁF2®¸!P&àØr 8›@‰J!£ r„-Pôàw‘r±ÜÉ€†,à®”g Ò,aH–²jE&¾ ÂF4®|·È…!¾P ž${Š/w@Ê+…ørÃ~ É@¨¸…+¬”‰0ÄØR‡+~é ûâ‹&wÅ'G ‹¾}…&½ÜqÄãJ¿x%½‘^þ*íôDzA¡ÒÔTWmõIÅ õÖ\wíõ×`‡-öØd—Ýu@;xerces-2_11_0/docs/style/resources/button-asf-lo.gif100644 0 0 2757 11474015642 17657 0ustar 0 0 GIF89a`÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éÎÈ LC ‚µhˆ5°üŠ e)°"X{Ô¼BDð‘,FPʘ‚%«”(n†¸RåË#[Ñ\É1Å ÊWwþÀšmiàJ¹¢ŠóEÕìW{ ÈI-—©¼Ó U+ ‘`x2E‹ãë‘Ÿ`DÞøº”(ØQÁ ÿ‚>ðL¬`¿Ô:e¨+(Š‚;?'?˜ôÄZõ¥O0=ˆ„—ˆ1 »°’Æ.«Â`Cñ‡› 7rP †Ñd (P¬RÊ%»ìÒ0ƒÀL$CØRÊ'¹œ1PÑPâËPÊ B¡ +©¤Å(¾¤!ÐCD3,ÀàaH0®°B™@¥Ð"P&ÁÈQË*…ä² Á$Ç XX—@qäBK*œØÒ e‘øBÄ$CвËPD‹"¹! A›øbI0•@ñJ/[Þñ0«¨L )P¯ÄÒ&Mž"t d Wf) jÑ°&"€Èâ‹™{9D0”üÔ 0q@±‡|rh *QL*jD fŽhÂF°¤B-jØ Aòk*+>ÉI—ô‹*Pàñ_€‹ü1‡¥Ì$¤–F4¡ Œ_±HˆI0¬b$Cô¡†+¢|…©œÅ®L©‡+˜eâÊPXbJCà1pÄ£<2'­A! (¦½’¬ dâš+tôáÊC@"‡aPPÂY)rôFɽ Ïq ,C„R/^£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éÎ4øª”N² 0"ò¨Èž8E$AqõI”)(“l¥éSäŽ@HEÜ*‚茭G‹€!y5g`JÁˆb“V®]¨è@ًدL_ž™'¡Þ´_-yS žWÉö€³ÔÜ®8à0‘¦8?™¶¹Èœ!PàNýÿWè‘¥Gà@ ¼N¥m¬Ô€£E «7Ô”0Š4D ÂA i”QÐo=² $ڈɮ@aŒ+©ˆ „$ÚÈaˆ6ˆ$#'´Ø2Û„‹»|’°B̀풌@¨ˆÇ6©¢M(‹€3ˆ{ìa †èáH!ƒ’ŸôQÈ)œHpÍŒ4Ñ°r„6‘@±J6Æ€rŒ4À@áF2¿ø‚ 1ÚdBP4Ã,aI2ÃÀ" §PSÉ@Ñ(!Ð(.C6Ĥ 8ztR4iäÈ%´|òIPpRʨ¼ÑAôÅ/àŒ‚8àXÖã6qä*a ¤öÄE(@Þ1j Î%P(¢G˸Ç)t|#{Tc í±÷ˆÝTFBqHDSÉP¨±Ê%Q™×”}bL!l$!‹lC dÆ,"Ð%Æ£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éÎ4hJI¥ :•(Õ8©A EÉ&(ŒR¥Á“jŽ@E©ØèI¨L*D…†Ð2gà—F¯`eR“¦Ô*Vœä@¹S ÖH_ž‰ã&¡Þ´MÕr³+Q¶îkt(Ø*8ÁUê•ÆU0<|±h(˜ŸJÁ4éÿñŽÈQ¢`•> f‰Ñ¯Oi‚bì“›"´ -¥aI¢èE¹ô›A‰D£ˆ/½@ (P '½Ðˆ/qøáK ¶ôÉ)ª äÆ/–”Í*“ä’z|R„€­b‹@ÂñK'zøRI!ÁôÇwøLjôчi¼A }dIAG.±¸ò ,¾,Å'»Q ± ¶ 1Ä&XBB+²ÔâH²Æb&¹42+´t †Ñá ,i(Ì’ìËŠP”w %”¼E$™ÌÁ‰ŽHp}1D0—L0²ñø «É@©Êx×AQ "PP¼ iÈŒ#P r‡Ñ„ò†&qÈjÈ»¤¢{Ž“HÀTvJ4ˆþ‘Ê!¬4RÆ€Ÿ<òdy]z%Dô¡†,§ä¦Æ+§@FD!=BD"šºrƱl2™@q v@I»¸RG»ø¡F'EܲŠgñ¥ ñ"°ØBË'×B±&­½ñÇ%™Ç'”ÀØí@˜â¥2FQ®ìrEzA¡ÒÌ4×lóIÅ óÎ<÷ìóÏ@-ôÐDÝs@;xerces-2_11_0/docs/style/resources/button-xml-hi.gif100644 0 0 2670 11474015642 17666 0ustar 0 0 GIF89a`÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éÎ<Èé›9¶ )Š†J¤]úкc0Q4I?ÙåJ@S²à4m :JA‘#ËŸZE¢"øè—±Uo Œ*’Ëã8¬Ý‘`Zƒ{D¨’E Ê&p¹Ü ÇH¸@k–J´c—ý‚¢G8ȃºÿqä*­ízÀ)Z•¦FSõ(,(ÁzAªË:µGŒ q^¿ 8"XöÉ6K¼b sÎAG" B#ÖùB‡4Â@±Ê±#8u TË6»N"ìE“K$½² P,0¹ BÍ)v€IŠ$2 o5Ž6–…"Ì)à˜¢M#” 8œP E H"gP“Ë*àè! 8r dK5 €¹Þ|2,Õ¨'ÝÄÑ‹6ÚPãFz‹8²CT AwT“J4"‚’™”à„â ‹ ñ†/Ó¼"uäÌr:Î.´4é耄bH-Ûá¡{˜ ²GCè •³KG°â(eCL ªlh]BK{ürÈ#CœÅÑ òG/½ü2J$¾ô‘‹›{ô²ˆ)¨ ÄɲP˜òÊ£Ä.xŒ² sìH Øj‹0…ir„²Ì…+œ@‰/wÜa À°rì^xE¬W|‘^P¨¤ñÆw|’@1„,òÈ$—lòÉ(§¬òÊ,“;xerces-2_11_0/docs/style/resources/button-xml-lo.gif100644 0 0 2662 11474015642 17701 0ustar 0 0 GIF89a`÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,`ÿ¡H° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜhÐ‹Ç CŠI²¤É“(S†,Æ‹À–/]B9S&Í›6sÆÜY“'NŸ:{ ¥‰ðçРF“"] ´éQ§,ÁHõ"µeUªS¯jÍÊÕjW¬^»UlY²`X:Uº–éÓ·lẕù’£Ý»éÎ<É”š8ªþ bÊ¢Uzðœšc0+F)¥ZêŽ@L§ÞüãŠÈ©8’0A‰S T©X]"ˆh‘On \šJ”7ŸhÁÝ‘`Zƒwzq: J¤`«ØÈ fhP°=Q{• +"Žr rÇW0È}€¥ÿB*Щív‚ *Œ¤CµO”«”W®í²Ï*—"C£¤×oÉ׋e“øB„)D0çtÑÑË&Ñ …+CÄK,P|K)¯ÈŒm¡ +C{®¬²È@¦D£”üòÆ«RD&r£Èƒ" oŒ/–U‹&Á`ÒKsÏI0‘Ds ©ÓK.ƒœ‘Ë*Ÿs‡%ÁÄ1P*»TæŠíIâÇ@¥ìR]$ÀÀáŠ/¾ÁFz… âK/CD Asì +!R"KüÁ\ ÁX‚ˆ…ˆâ†+µ˜K/r¬’auˆ wJ“ŽŠ¢G% ²]ê±÷ wÈ—1Ê‹P¹«|Ë'ÎU¢+,{pòK uDÉ)iÜ1ĈŒRs¸Ò‡®`xÉ"®à±ÊܹR&œ  ²P`bJŠ¼BË*t\òÉh¬è±GµC\BÇ…A -ŸA!J$P<âÊr¤BËïö&(^ o4`Ã_¤*UlñÅŸ$P wìñÇ ‡,òÈ$—lòÉ;xerces-2_11_0/docs/style/resources/changes-add.jpg100644 0 0 1736 11474015642 17332 0ustar 0 0 ÿØÿàJFIF``ÿÛCÿÛCÿÀ!ÿÄ ÿÄ% !X˜ÖÿÄÿÄ"2ÿÚ ?¦}ÜÝM»¨öz/\¢•üˆPÍ~¬­ÇÉ×kÆõ•:-9±î¨a2^¦µà¬cQñŒ«Pj3è°gŽ‘,G¬ všI5AvÚ>S|ÄÖ±yTÍmX«ÞF!ѳ’£Ç jÓE äÁBßØ Ð=›6ŽzýÆ] ͲJ9[¿I<¸ÊÂíÞÛ¡’ÌyCè÷&éžÚüNs'Ѩ{×M?sVÀR/œ•¦Ç²Ö·¿ÔØ“Q̪7îòŽ;r³ñèöèÙÇ©{£÷û{ì¯b½V^µô—+àúç¶ÍI3½¿‰îLˆ=qGË]5ô/T¤yyº³–bÖ~?u隯I*Ý»w8:¾6ç?ˆná؃hbL‚m–É’>ÅE•Å«Œ’û$§}"½å¬­e;1²…•êŒ`ÀÓWä0lQ¬´³¶"m ÐärÀzŽ¨HËIêú¿ãd“‹N Æ[VE bíUK–<¤BCCž¯˜±QÁ‡µl;ªK&?‹mAFÌöŽ¾§È‹A|I±.”³#»¨î‹ô,§lßE LÅeÔ–¶$IwÛEÃp3ä @•jT`EÈ{\ÅvQo‰jÿeë}:…Ù+f«8Ýv¬Ž&5; …Ö¼(úŒT¶ðGз³ 21svòAe#“±Ü°²ç¤C86¡Ëz£`+WlÚ$lµcÕl°+sª|Ôm¨E²ÚgQ7öµß_vÖê¿,šðö`RÃRó«ˆ mâË°JÊ YöÕàSò=ŒûZ-ô1§¢Œhm§ðë&ÛlJoYrw¬y*S,²ypÍ~‚”Ñ¢jº:kª'qLY~§ ϱ™ISM+×Ï.“¥ýèߎ4â×Øv>Ú¼£ÖyÎ9ô³ÙUö:¿ ×OŒvŸH¢¢Rí–xv'ï†sƒ±×]%–*–µ›b¶¶E¾ëhN!ÕÞ0‘jÄU"‘`%µ§3›D°k÷¥Rw˜3|þ°Ì’Í$’a}›:Bñ³Às 5<å•h‰D>ÕÕ]I¬CÃØ#ø@#ü gú!\º/–êù­XYUÒŠµ‹´è¢’gºnèÀ}#2MïÈ6u…§e¦Ç5àmÉíÀË,5ª3‰€}ihü Ž¯0‚+X³@Í —(ia$¢É€F™æGÍ6L~¥Î<’V—“¨§¨ƒ°¨¨°&¥… #Š¼¼Tx‚ƒ .$Q¢D‹è£Ã‡ |8ñù8ãŸÿÙxerces-2_11_0/docs/style/resources/changes-remove.jpg100644 0 0 2343 11474015642 20072 0ustar 0 0 ÿØÿàJFIF``ÿÛCÿÛCÿÀ!ÿÄ ÿÄ! ÿÄÿÄ!ÿÚ ?Ô~°o©ÂÀ¯‘ô5ÉS¢¢ç̼Ú9R¤^Í2?ªÝqY;0#SÛÇ8^†>ùñF£8DÐ!~Ìïü©½:üSïËgKWÔΔnDö¡%ÙtFtu»z¦œëè÷QŸ¦Ÿd¯Š5­ŠÄ‹l¾)n µ«8HytýÏ%v¸¢KršØ÷ÇËò¦Øªúª²ôŠÌ¾è’è¾±9ÅLÈæ5VÅV1ÑŒ/3,°‡“0Aåó¢&C(ȹ’‡*4è2{Æï˯‘ññò@é—ÄjÃØwkNCÐK[.ä5ªüÿÚƒŒõcì ÚY­6A”Øx’ð(jæïúL3ICÅC _#nÖ± ‘ÝÕwĆjýÄÏb5Ó&¾²| €p6ƨù)æÝ+[&6é6ˆÐÕÝñ÷+fÒÍ™f‡^)¸)CáÚkê Ýn½Ÿã»–jUì㇩È”ž|©E·Cz¬›yÌçí¥”0‘œˆWB÷œW1 ÂX/iY ¢Î þ¢q‘è—•Åëy/ê¼—CÍö•ìâöØ8‘ñÔQÕÊè³°¤¾¾=Köhò²ÅTiiÙM‹ãT§sz—)š¢ôÝ„ƒˆU#Q+“ÿo7GB·¤šcek¤™¥Cj¸«RttV†å¼õÄ9Ã| Š®“ϳmÄ>ûíhh6+œþ“¸Ï–žgÕÿ›Ïú-'Åôdúo36¥ý úí6a°˜¯ðdg˜e¥¤Y›»óCûîïµõûê9èäúmõƒ}*i‘ÜÞîõ«Þ¿>xå"šTGÐû*iÈ…¬T’Õˆî½7¾z§ôºG*òéQÿX· €C`nO´&4+µû‘â5™-ñÒËÒC8SJ’eE) '•HÉ”¶ÆpQ§£ÏYç:³›¤,SL6BÙdû¹}m² ÎwU`²‰y¯´íßÈøv@ (àY ý¨ì Ñ’C™ðœ5=n0ÌÂ- !Õ–˜inèiî~D´ ÃK?þL‡óø-Í®®‡¤(Z^å.´Œõ-l0 P/EBŠKÉfš‘[0ƒ:ƒû²%IRU^qªÒé:M,]X×âú XXÒt¿®?RçK.`¹så‘>ÒØÒ|‰V—gf’¦œ\ pp:qœábÓ€PÖµ¬D° ÁÁÌÌÁÌÌÌÌÏ“UTÛMÛCë²·¶ªë©¬¢š©¡„×ÑCÚF×=Í3cZÃ&1„FdD[»ÿÙxerces-2_11_0/docs/style/resources/changes-update.jpg100644 0 0 2166 11474015642 20062 0ustar 0 0 ÿØÿàJFIF``ÿÛCÿÛCÿÀ!ÿÄ  ÿÄ ÿÄÿÄ"ÿÚ ?±ÒîQžBÖ+ r^åv8kÏg*Ö#iFj·Ö¯q®&:c° ¤é¬ X –²U£ÅóEêM¬#Ǻ^%™šŠ"Ôh«¯õ¨êPLÂ$º¤›ÂéâRzyÒß ¶T!KuåÕœÊ9 Ñ(‚Zví9pŒ²"M’‘–<9Õ}áL‘g?õRÂöžAsº÷o%ÄßÑçJhmv•ëd¶O)ŸNÛ[Ü¿»%ˆs(Ô²µ¦‰T<)%û&úðO u`ÐÓ–É[§ún§/7¦’\ü~6Í­Xôz[·*˜±êb%i4-Ø¥ö"ÞO°ÐæÖ- ·b ÞÄ´sa›J.›q§KÔv1'ú.¬^äcrF«b(dˆ €û»P72†÷á0[é—*VйªÞÒâH[é¢ûîê¡yQanÃçrG4qˉ,R¢É±²¼rFê$Ô•tu!•”•e ‚AÅK£Æ쎬ŽŒÈèêUÑÔÊÊ@*ÊA ¤ Ÿ%7ö[µ5/F:™.8¹=¦np§>£•Ç×Ö•Q¯ã—½K²/çFß`Jf ¯ê+*MôUÜáÐHå}v¼3žÂgÇœöö~t×$%À é!ÁäÞ•7Ø}zÔoî~¤Ð·–ÇÇí·cý{U3Ø` «¡Ð¥ÅˆyÖ½¶Ñ¶ŒÍ)ýiÓ~'aãpw¶zý>>î½ìsQúÓ[šž >· ; ?Ÿö6E›Ÿ²ÿEzB<½š¨ÚEmŒñóÕšÄWwz×]J‡«ró­Mþgœ‹zm,Ó|¶FÅ«ZÚùÍs;õI>ÎFź–B²·×)ã¡œVÚ&#ÎI•ÒHEÍ ôr-6dÅ;«&›žnÙºÌŞɹ¨ª£„RÕi˜O½c5M}©…4áŠPN_i«ÛK¹›3>«Ž8áŽ8¢"Š$XâŠ5TŽ8ÑB¤q¢€¨ˆ *ª€ª y„wyÙÝ™ÝÝ‹;»Y™‰%™‰%˜’I$“óâŸ(òßPb1‡KsZ¡ð Êç0ÌiÅÛkÈü«ð‡!ŒO‡< Ê÷Ê:O.rªò'¶žSÕù;ÝþWÄþ9ûéù?ÿÙxerces-2_11_0/docs/style/resources/close.gif100644 0 0 762 11474015642 16244 0ustar 0 0 GIF89axÕÿÿÿòòòìììÛÛÛ×××ÅÅÅÃÃû»»¶¶¶²²²±±±­­­©©©£££™™™–––•••’’’‘‘‘‹‹‹ˆˆˆ‡‡‡‚‚‚~~~}}}rrrqqqnnnjjjiii,xÿ@‚B,ȤrÉl:ŸÐ¦æ#ŒZ¯Ø¬VJ&¾à°xL.›Ïè´zm†L«™¸|N¯Ûïø¼~ÏïãÝ][‚ƒ„…€U†‰Š‹F D —™˜šœŸ›¡ž¢ £¦¥¨¤ª§«¨”˜ D¶¸·º°½Ž¾À¿ÄÁÅÃÆÉÈËÇÍÊŽ¶ G˜ÙÚÛÜÝÞßàáâãäÙ µE¬ð©ñ­ôóöòøªÜyFYAg"\x°a¯:, À ,H8W®£GsŒ¶d‹P¡_+øÀƒ?0cÊœ9³Â… Q¦¤X`Â@ƒ J´¨Ñ£H“*]Êt…ÿR;xerces-2_11_0/docs/style/resources/dot.gif100644 0 0 61 11474015642 15675 0ustar 0 0 GIF89a‘ÿÿÿÿÀÀÀ!ù,”U;xerces-2_11_0/docs/style/resources/join.gif100644 0 0 2364 11474015641 16115 0ustar 0 0 GIF89ax÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,xÿÅ 8]½ƒë*¬goŸ2Z HœHÑ #æÞ¬—ã†#Ri£Æ…;‚„8’äÅŒS.Ô÷O»›8qn¬—ï`Ož>ó­¹Ñr¢/:”}‹·ó§Ó C‹J<štiSŸXy %*•ªR¦Ÿ¥is§Ù³gïݛŵ¥™+X0¶›‡6íÚ¶#ßÆ57·®Yµl»Â•K×ïA²=*–¹xã¼{ H™1cÅÌT+^°Ì€Ž)cÆõGž\ùræÍ« Y2eËP(ŸæìåÌš‰ê+6´<³t°°‡ :Œø/lÖÞó~^üxòåÍŸk?¸pâÆ‘+Ùgî|7VĆÓ×£7O:¼~èØñÈ2sèàÑS¿“½{øòÑg~úñ·‘ïÅ7_}÷å·è©ö™mܵsN9âx39æ|ÓXNXá…nØá‡;‰Ú<b¨!‡‚(ámemÇÛvëÉO;é°ÓÎ;ñv•yDæ¸c?yÖEÒ£#>)dy7Fhà•Xf©å–WZÉå—`†)æFè­cæ™h¦©æšl¶éæ›pÆ)g›õ —Ïxæ©çž|öé矀*è ~Ö‰Û˜ˆ&ª¨a^.êè£`Ò;xerces-2_11_0/docs/style/resources/line.gif100644 0 0 1634 11474015642 16105 0ustar 0 0 GIF89aÈ÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,ÈiH° Áƒ*\È°¡Ã‡#JœH±¢Å‹3jÜȱcE0 CŠI²¤É“(Sª\ɲ¥Ë—0cÊœI³¦Í›8sêÜ9ŠÏŸ@ƒ J´¨Ñ£H“*]Ê´©Ó§P£JJµªÕ«X³jÝʵ«×¯`ÊK¶¬Ù³hÓª]˶­Û·f;xerces-2_11_0/docs/style/resources/logo.gif100644 0 0 6227 11474015642 16121 0ustar 0 0 GIF89a‡<÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,‡<ÿÁ §Ë4*\È°¡Ã‡#JœH±¢E‡‘ù¨A† 0 CŠI²¤É“(Sª\ɲeIp³€Ñrã ”›8sêÜɳ§ÏŸ@ƒ J”'8Y\¨)Ê´©Ó§Pu‚ñòsª®`–FÝʵkÔ©PÀÜv¬d´x]˶mO°P¨Æ½Iu*&7ÜêÝÛî[/9ÐØäK¸0Q°d›¥AÖ°ãÇ;áÊÖ cž›X±Út“3Ϲ6m¢¹4S¿<§^æyèNÏ°MË.Šx¬íÊ«w¶ÆzS®›½]Ïþ—®ñ¹ªëÜݹùgâЋûLÞ“ùóë½IGß^»¬wêÛÃCÿ•|¼®eå@çˆÞ$¼óúÑ9Õ‹nÓï\¬Ú‹ÖNIôë÷þéÔˆhn¸çÙg¢5ÅëÍážvB¡ÙyD™2P09 4Ðo7Y(†8¹Œ†àh'‡¹„‰*ê4Ç2àÄ%)xÓ†Ÿ $܉‡Õu[bµ8C‚ãàDn#8{Ü4d‘GBÁŠ@¦4²d™Áp€<Ð@x°Atp*¨PAçN”ÀÁ擾›eß¼S `ð€¨=À Dà@8{¡7¯B ¨`B%$9 $¿Voœõ¶ï‚¦lbJ“Íe·àf¦|¢ÙÌ8 Ü¿ò9! Jgìî ˆž¦W½È-·kÀT° ¤ HÁøF¤Àâ»@ Ô•Øxæ}ïƒB 93³¯¬5&û­l†8û8'‰4£ }hÛ 'Q°Â^ „b,ÀçøF~ÀJùÔTÉô¦;ýéPºÔ92TÍiOƒZÔ¤6µ¬iÍê[¿Z×M¦K ­Ð‚ÃèPG:Ò¡tœc|h ±le3ÛÙЖv±ìe7ûÙÑfÊ´¹míogÛÍbiLÆÐe|ƒðpÇ<æáŽx»#|ƒ£iügv»Þò¦·½ñ­oCÏð&ën÷»ã=ïz»ãÞùÞ7û­p€7|à7øŽ/=.¼  ¯‡ÈG.r{ÌB bÿh°¡Ðñ‡œä#79ÊUŽê›´äð†yÌOžrœùæ/×¹Ì{¾rLU¡B0GÎ×!r¦×ƒéöøÇÈðŒ =éKoºÖ£>õªåêJ‡ÇÓµ>v®SÝêHûØ×u©Ÿ=(ÞÚÂÇÑ!v‘çÃîvÇ?p±µÜ r/ÝG~÷z>zç»ß ø¹×Ýðx7|âûÞçÆ þñ‡ÏûÞ)ÿhoq P‡;tNr{äƒ2(xÍ¡ðùОô%?}ê}ÞâÖ‹ö±G½êlû×ÃÞôº§=ª½Õ…x#ó »ÓŽnÌ A)þñ“Ïv²7ÿùÑ7>ò•o}çC(Òß~|õ×®ï % q±ÄÁ’gòz_ƒ`þŽƒŒ£ý„üÝã?Æ×ÿþî§õÀ6áö‡yúð4~'vvÆ~¸7r÷À„€Áf6ðäÐ(r˜yQsè ‚#¨&Ø‚õ°€(4(;xerces-2_11_0/docs/style/resources/note.gif100644 0 0 447 11474015642 16104 0ustar 0 0 GIF89a³„„;¼¼Xww8¨¨PPP(ÏÏikk6ÙÙsÃÃgää~^^5í퇵µgõõüü—ÿÿÿ,ÜPÉI¥‘/gźïH^ÚÃ} #"œ¢ß2Fçš±\ D=0.˜JÚ†dRZí ‚€0 Ž¬(¤ÈV±-ì€Â”šHdæ‚p= ‰ƒ›\D˜£tbmmHEqjx„ †ˆ^ WjŽnˆ<t„m  Hq  ž  ¢fvh“Ž¬™vXz¶­ ½¤=]¾   ËÁ½ŠS –ɶÌÁ€hÓÊÌÂU=–ÔÝÞbQåæç„ŠíÞôßGøùøèüþþ;xerces-2_11_0/docs/style/resources/right.gif100644 0 0 2262 11474015642 16271 0ustar 0 0 GIF89a<÷ÓÔÕIF|M‚ÌÏÑR†[ŽV‰c•`’_‘ÔØÚ¥§¨mk›išh™g˜e–Îäîíöúw¦v¥u¤t£s¢r¡q pŸožn ˆ±»×⟮´ñøû®€­¬~«}ª|©{¨x¦x¥iŽk‘•Èf‰b…^€ ¨á«å¬æ«á n“Š¸ q˜±çl‹ nŒD¾ë;œvÐñZ”©u¸Ðu·Ïo›¬£Óä²Úè¸ÝꢽÇÓêòÙíôØìóÚíôÞïõžÓ‰µ‡³…²†²…±ƒ°„¯‚¯~¨{¤vgŠ¨â’Ây¢vžsšr™‡´šÌ™Ë–Çm’£Ù‡³€«ˆ³›Í‰´ ‹¶¥Ø Œ¶ i‰Ž·¸‘¹’º”» •¼!–¼#—½$—½&˜½*š¿3³Ý-›À0À/•·3žÁ4ŸÂ6 Â8¡Ã;¢Ä3ˆ¥>£Å;š»?¤ÅB¥ÆD¦ÇF§ÇH¨ÈJªÉN«ÊQ¬ÊT®ËV¯ÌY°Í]²Î`´ÏcµÐdµÐe¶Ðg·Ñi¸Òl¹Óo»Ôr¼Ôt½Õu¾Õw¾Öy¿×†Ðé|Á×~ÂØ€ÃÙ‚ÄÙ†ÅÙt¨ºŠÇ܉ÇÛÉÝ‘ËÞ”Ìß“ÌÞ˜Îà™Ïà™ÍßžÑâ¨Öå«×æª×å®Ù献¹°Úç´Ûè¶Üé¹Þêk€‡ºÞê¾âî½àëš´½ÄãíÇäîÊæïÌçðÎèðÐéñÖìóÕëò·ÉÏÛîôÜîôåôùâñöËÔ×î÷úmpqæìî’º¹¶ÁâìÒêñßðõåó÷ëöùšÀ™¿–½éõøöûüúýýijjýþþÙÚÚ¾¿¿ÿÿÿòòò×××ÕÕÕÐÐÐÏÏÏÊÊÊÅÅÅ»»»···µµµ²²²±±±­­­©©©§§§¥¥¥   ™™™–––•••‘‘‘ŠŠŠ†††~~~}}}yyyrrrnnnjjjiii,<ÿiH° Á,2òxǘ‡#Jœˆ† ™,š¦1„±£Ç ¿ÜÐrã$ÁxÉ’¥MàR®Ñ&›8AšÁ2J&Ç•P€ ýùÑ A>[*åhƆ Ÿ9oÖœ*µ#I‡%ºµkÐI—*õ¶£ÊªQƒzY˶mÙšZã.}{èعP©Ú :1"ݳ]ã¶L6lK»,ÿÎÔÛ1HÅ\ãö…y)áÁ£îuü±²\¯‰ ³ô2ùafÆ?/³õ™kËÊw•žFÛ¸4ÖS«.l–óGßg§Î·äÒ°ïæ —vU㶆ÞY4HÒÈó:W»Ûøô×Öã—íí|³mï—'=¾¹æÆíëNz>¼ÇåÌå¿wš|îÿ¯íØXç ¸ØvøÅ`à|ü=¶ es-¸_M“A¡ ŸYvasbµ¡~¨M:<øÙgMõð`‡ EŠ„!RÕ‘^´‚‰ zeÆXâ‹-™a…XüÐŒCø톃 ,´AÊ‘àÄ å”TVi¥=BCà;xerces-2_11_0/docs/style/resources/script.js100644 0 0 1006 11474015642 16322 0ustar 0 0 rolloverImagesOn=new Array(); rolloverImagesOff=new Array(); function rolloverOn(name) { if(rolloverImagesOn[name]){ document.images[name].src=rolloverImagesOn[name].src; } } function rolloverOff(name) { if(rolloverImagesOff[name]){ document.images[name].src=rolloverImagesOff[name].src; } } function rolloverLoad(name,on,off) { rolloverImagesOn[name]=new Image(); rolloverImagesOn[name].src=on; rolloverImagesOff[name]=new Image(); rolloverImagesOff[name].src=off; } xerces-2_11_0/docs/style/resources/separator.gif100644 0 0 156 11474015641 17133 0ustar 0 0 GIF89ax¢××ײ²²±±±•••~~~}}}iii,x;2Üþ0ÊI«½¸£²ÿ`(jÜœhª®lë¾p,Ïî°uD®ï|ïÿÀ pH,m¥‘rÉl";ΨtúØ$;xerces-2_11_0/docs/style/resources/void.gif100644 0 0 61 11474015642 16050 0ustar 0 0 GIF89a‘ÿÿÿÿÀÀÀ!ù,T;xerces-2_11_0/docs/style/stylesheets/any2header.xsl100644 0 0 2414 11474015642 17600 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/any2project.xsl100644 0 0 707 11474015642 20001 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/book2group.xsl100644 0 0 1743 11474015641 17652 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/book2project.xsl100644 0 0 23656 11474015642 20214 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/changes2document.xsl100644 0 0 1710 11474015642 21005 0ustar 0 0
    • xerces-2_11_0/docs/style/stylesheets/context2footer.xsl100644 0 0 2027 11474015642 20543 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/context2label.xsl100644 0 0 1176 11474015642 20330 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/design2document.xsl100644 0 0 6656 11474015642 20664 0ustar 0 0
    interface class
    extends ,
    implements ,
    constants:
    methods:
    • void ( , )
    [] COLLECTION     xerces-2_11_0/docs/style/stylesheets/design2html.xsl100644 0 0 12734 11474015642 20024 0ustar 0 0 Xerces 2 | Design

    Design

    Classes and Interfaces

    Last modified:

    extends
    implements ,
    constants:
    fields:
    constructors:
    methods:
    ( , ) ( , ) : [] < >     xerces-2_11_0/docs/style/stylesheets/directory2project.xsl100644 0 0 1652 11474015642 21236 0ustar 0 0 xerces-2_11_0/docs/style/stylesheets/document2html.xsl100644 0 0 50471 11474015641 20370 0ustar 0 0