1 / 45

Effective XML

Effective XML. Elliotte Rusty Harold elharo@metalab.unc.edu http://www.cafeconleche.org/. Part 0: Should We Use XML?. The XML Backlash.

britain
Télécharger la présentation

Effective XML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Effective XML • Elliotte Rusty Harold • elharo@metalab.unc.edu • http://www.cafeconleche.org/

  2. Part 0: Should We Use XML?

  3. The XML Backlash “With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML.” -- Apache Wicket

  4. Choose XML • For data that must be exchanged • Or extended • Or stored

  5. Don’t Choose XML for • Purely local, transient data (e.g. internal method arguments • RPC is an edge case

  6. Why Use XML • Well-defined, well understood • Secure • Extensible • Fast • Easy • Robust • Internationalizable • Platform independent • Language independent • Not executable • Standard parsers easily available

  7. Avoid • JSON • YAML • Java Properties • Custom syntax • Etc.

  8. Why? 2 usually orthogonal reasons • Mixing Data with Code is Bad • Unportable data • Opens big security holes • This is why you want to use XML instead of Ruby, Python, PHP, etc. • Weak Parsers • Bugs and security holes • Not internationalizable • This is why you don’t want to use YAML, custom file formats parsed by regular expressions, etc.

  9. Limited Use Cases • Works for: • Lists • Maps • Sets • Simple config files • Not so well for: • Trees • Networks • Narrative data • Annotated data

  10. Choose the right tools: • XPath, XSLT, XQuery • E4X, XOM, JDOM • RELAX NG • Avoid • Regular expressions • DOM • W3C XSD Schemas

  11. Part I: Syntax

  12. Stay with XML 1.0 • XML 1.1: • New name characters • C0 control characters • C1 control characters • NEL • Undeclare namespace prefixes • Incompatible with • Most XML parsers • W3C and RELAX NG schema languages • XOM, JDOM • Many browsers

  13. Part II: Structure

  14. The XML Stack

  15. Allow All XML syntax • CDATA sections • Entity references • Processing instructions • Comments • Numeric character references • Document type declarations • Different ways of representing the same core content; not different information

  16. Distinguish text from markup • A DocBook element <programlisting><![CDATA[<value> <double>28657</double></value>]]></programlisting> • The content is:<value> <double>28657</double></value> • This is the same:<programlisting>&lt;value&gt; &lt;double&gt;28657&lt;/double&gt; &lt;/value&gt;</programlisting>

  17. The reverse problem • Tools that create XML from strings: • Tree-based editors like <Oxygen/> or XML Spy • WYSIWYG applications like OpenOffice Writer • Programming APIs such as DOM, JDOM, and XOM • The tool automatically escapes reserved characters like <, >, or &. • Just because something looks like an XML tag does not mean it is an XML tag.

  18. White space matters • Parsers report all white space in element content, including boundary white space • An xml:space attribute is for the client application only, not the parser • White space in attribute values is normalized • Parsers do not report white space in the prolog, epilog, the document type declaration, and tags.

  19. Make structure explicit through markup • Bad <Transaction>Withdrawal 2003 12 15 200.00</Transaction> • Better <Transaction type="withdrawal"> <Date>2003-12-15</Date> <Amount>200.00</Amount> </Transaction>

  20. Store metadata in attributes • Material the reader doesn’t want to see • URLs • IDs • Styles • Revision dates • Author’s name • No substructure • Revision tracking • Citations • Single item only

  21. Remember mixed content • Narrative documents • Record-like documents • The RSS problem <item> <title>Xerlin 1.3 released</title> <description> Xerlin 1.3, an open source XML Editor written in Java, has been released. Users can extend the application via custom editor interfaces for specific DTDs. New features in version 1.3 include XML Schema support, WebDAV capabilities, and various user interface enhancements. Java 1.2 or later is required. </description> <link>http://www.cafeconleche.org/#news2003April7</link> </item>

  22. What you really want is this: <description> <p><a href="http://www.xerlin.org"><strong>Xerlin 1.3</strong></a>,an open source XML Editor written in Java, has been released. Users can extend the application via custom editor interfaces for specific DTDs. New features in version 1.3 include:</p> <ul> <li>XML Schema support</li> <li>WebDAV capabilities</li> <li>Various user interface enhancements</li> </ul> <p>Java 1.2 or later is required.</p> </description>

  23. What people do is this: <description>&lt;p>&lt;a href="http://www.xerlin.org">&lt;strong>Xerlin 1.3&lt;/strong>&lt;/a>, an open source XML Editor written in Java, has been released. Users can extend the application via custom editor interfaces for specific DTDs. New features in version 1.3 include:&lt;/p> &lt;ul> &lt;li>XML Schema support&lt;/li> &lt;li>WebDAV capabilities&lt;/li> &lt;li>Various user interface enhancements&lt;/li> &lt;/ul> &lt;p>Java 1.2 or later is required.&lt;/p> </description>

  24. Part III: Semantics

  25. Include all information in instance documents • Not all parsers read the DTD • Especially browsers • Beware • Default attribute values • Parsed entity references • XInclude • ID type dependence (XPath, DOM, etc.)

  26. Encode binary data using quoted printable and/or Base64 • Quoted printable works well for mostly text • Base-64 for non-text data • Can you link to the data with a URL instead? • Can you bundle the data with XML using zip, jar, XOP, or MIME?

  27. Use namespaces for modularity and extensibility • Simple cases can use one default namespace • http URIs are normally preferred • DTD validation is tricky • Code to namespace URIs, not prefixes • Avoid namespace prefixes in element content and attribute values

  28. Reuse XHTML for generic narrative content • <!ENTITY % xhtml1 SYSTEM "http://www.w3.org/TR/xhtml1/DTD/strict.dtd">%xhtml1; • <!ELEMENT description %Block;>

  29. Choose the right schema language for the job • DTDs • The W3C XML Schema Language • RELAX NG • Schematron

  30. Use only what you need • You need • Well-formed XML 1.0 • A parser • You probably need: • Namespaces • You may not need: • DTDs • Schemas • XInclude • SOAP • WS-Kitchen-Sink • etc.

  31. Always use a parser • Can’t use regular expressions: • Detecting encoding • Comments and processing instructions that contain tags • CDATA sections • Unexpected placement of spaces and line breaks within tags • Default attribute values • Character and entity references • Malformed documents • Internal DTD Subset • Why not? • Unfamiliarity with parsers • Too slow

  32. Layer Functionality

  33. Program to standard APIs • Easier to deploy in Java 1.4/1.5 • Different implementations have different performance characteristics • SAX is fast • DOM interoperates

  34. Program to non-standard APIs for ease of development • JDOM, XOM • E4X

  35. Read the complete DTD • Be conservative in what you generate; liberal in what you accept • Important content from DTD: • Default attribute values • Namespace declarations • Entity references • ID types

  36. Navigate with XPath • More robust against unexpected structure • Allow optimization by engine • Easier to code; enhanced programmer productivity • Might be slower

  37. Validate inside your program with schemas

  38. Part IV: Implementation

  39. Write documents in Unicode • Prefer UTF-8 • Smaller in English • ASCII compatible • Normalization • É, ü, ì and so forth • NFC • ICU

  40. Avoid Vendor Lockin; Beware • Opaque, binary data used in place of marked up text. • Over-abbreviated, inobvious names like F17354 and grgyt • APIs that hide the XML • Products that focus on the "Infoset” • Alternate serializations of XML • Patented formats

  41. Hang on to your relational database • For tabular data • But consider native XML databases going forward

  42. Pick the correct MIME type • application/xml • Not text/xml! • Don't use charset • application/mathml+xml • image/svg+xml • application/xslt+xml

  43. TagSoup Your HTML

  44. Compress if space is a problem //output OutputStream fout = new FileOutputStream("data.xml.gz"); OutputStream out = new GZipOutputStream(fout); OutputFormat format = new OutputFormat(document); XMLSerializer output = new XMLSerializer(out, format); output.serialize(doc); // input InputStream fin = new FileInputStream("data.xml.gz"); InputStream in = new GZipInputStream(fin); DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document doc = parser.parse(in); // work with the document...

  45. To Learn More • Effective XML: 50 Specific Ways to Improve Your XML Documents • Elliotte Rusty Harold • Addison-Wesley, 2003 • ISBN 0-321-15040-6 • $44.99 • http://cafeconleche.org/books/effectivexml

More Related