Perl与XML：编程黄金搭档，解析与应用指南

需积分: 10 10 浏览量更新于2024-07-25 收藏 915KB PDF 举报

Perl与XML是信息技术领域中的一对黄金搭档，Perl作为一款强大的文本处理语言，因其灵活和高效而广受欢迎。XML（可扩展标记语言），作为一种轻量级的标记语言，以其简单易用性和结构化的数据存储方式，使得它在网页设计、文档格式化、法律合同管理甚至书籍制作等领域大放异彩。它在Web服务中的核心地位尤为显著，如在SOAP（简单对象访问协议）和XML-RPC（远程过程调用）中扮演着至关重要的角色。 Perl与XML的结合，得益于Perl天生适合文本操作的能力。Perl程序员通常认为这两种技术简直是天作之合，但如何最有效地利用它们来处理XML文档和数据，却成为了一个值得探讨的问题。《Perl与XML》这本书正是为了解决这一问题而编写的。该书的目标读者是对Perl编程有基础，并希望扩展到XML领域的开发者。书中详尽地涵盖了Perl中主要的XML处理模块，包括但不限于XML::Simple，这个模块简化了XML的读写操作；XML::Parser和XML::LibXML提供深入解析XML文档的功能；XML::XPath用于选择和定位XML文档中的特定元素；XML::Writer则用于创建XML文档；XML::Pyx、XML::Parser::PerlSAX和XML::SAX则关注实时的事件驱动解析；XML::SimpleObject和XML::TreeBuilder提供了基于对象的XML处理方法；XML::Grove和XML::DOM则支持文档对象模型；XML::RSS用于处理RSS feeds；XML::Generator::DBI允许将XML数据与数据库集成；最后，SOAP::Lite则涉及SOAP服务的开发。本书不仅仅是一个工具集，更是一本深度学习和实践Perl与XML交互的指南。通过阅读和实践书中的内容，读者将能熟练掌握如何在Perl环境中高效、优雅地处理各种XML相关的任务，从而提升编程技能并拓展业务应用范围。无论是初次接触Perl和XML的开发者，还是希望进一步提升现有能力的专业人士，这本书都是不可或缺的参考资料。

Perl and XML

age 12

No matter how smart you make a formatting language like troff, it still has the same problem: it's inherently

presentational. A presentational markup language describes content in terms of how to format it. Troff specifies

details about fonts and spacing, but it never tells you what something is. Using troff makes the document less

useful in some ways. It's hard to search through troff and come back with the last paragraph of the third section

of a book, for example. The presentational markup gets in the way of any task other than its specific purpose: to

format the document for printing.

We can characterize troff, then, as a destination format. It's not good for anything but a specific end purpose.

What other kind of format could there be? Is there an "origin" format - that is, something that doesn't dictate any

particular formatting but still packages the data in a useful way? People began to ask this key question in the late

1960s when they devised the concept of generic coding: marking up content in a presentation-agnostic way,

using descriptive tags rather than formatting instructions.

The Graphic Communications Association (GCA) started a project to explore this new area called GenCode,

which develops ways to encode documents in generic tags and assemble documents from multiple pieces - a

precursor to hypertext. IBM's Generalized Markup Language (GML), developed by Charles Goldfarb, Edward

Mosher, and Raymond Lorie, built on this concept.

As a result of this work, IBM could edit, view on a terminal,

print, and search through the same source material using different programs. You can imagine that this benefit

would be important for a company that churned out millions of pages of documentation per year.

Goldfarb went on to lead a standards team at the American National Standards Institute (ANSI) to make the

power of GML available to the world. Building on the GML and GenCode projects, the committee produced the

Standard Generalized Markup Language (SGML). Quickly adopted by the U.S. Department of Defense and the

Internal Revenue Service, SGML proved to be a big success. It became an international standard when ratified

by the ISO in 1986. Since then, many publishing and processing packages and tools have been developed.

Generic coding was a breakthrough for digital content. Finally, content could be described for what it was,

instead of how to display it. Something like this looks more like a database than a word-processing file:

<personnel-record>

<name>

</name>

</birthday>

</personnel-record>

Notice the lack of presentational information. You can format the name any way you want: first name then last

name, or last name first, with a comma. You could format the date in American style (4/23/1969) or European

(23/4/1969) simply by specifying whether the

<month> or <day> element should present its contents first. The

document doesn't dictate its use, which makes it useful as a source document for multiple destinations.

In spite of its revolutionary capabilities, SGML never really caught on with small companies the way it did with

the big ones. Software is expensive and bulky. It takes a team of developers to set up and configure a production

environment around SGML. SGML feels bureaucratic, confusing, and resource-heavy. Thus, SGML in its

original form was not ready to take the world by storm.

"Oh really," you say. "Then what about HTML? Isn't it true that HTML is an application of SGML?" HTML,

that celebrity of the Internet, the harbinger of hypertext and workhorse of the World Wide Web, is indeed an

application of SGML. By application, we mean that it is a markup language derived with the rules of SGML.

SGML isn't a markup language, but a toolkit for designing your own descriptive markup language. Besides

HTML, languages for encoding technical documentation, IRS forms, and battleship manuals are in use.

Cute fact: the initials of these researchers also spell out "GML."

Perl and XML

age 13

HTML is indeed successful, but it has limitations. It's a very small language, and not very descriptive. It is closer

to troff in function than to DocBook and other SGML applications. It has tags like

<i> and <b> that change the

font style without saying why. Because HTML is so limited and at least partly presentational, it doesn't represent

an overwhelming success for SGML, at least not in spirit. Instead of bringing the power of generic coding to the

people, it brought another one-trick pony, in which you could display your content in a particular venue and

couldn't do much else with it.

Thus, the standards folk decided to try again and see if they couldn't arrive at a compromise between the

descriptive power of SGML and the simplicity of HTML. They came up with the Extensible Markup Language

(XML). The "X" stands for "extensible," pointing out the first obvious difference from HTML, which is that

some people think that "X" is a cooler-sounding letter than "E" when used in an acronym. The second and more

relevant difference is that your documents don't have to be stuck in the anemic tag set of HTML. You can extend

the tag namespace to be as descriptive as you want - as descriptive, even, as SGML. Voilà! The bridge is built.

By all accounts, XML is a smashing success. It has lived up to the hype and keeps on growing: XML-RPC,

XHTML, SVG, and DocBook XML are some of its products. It comes with several accessories, including XSL

for formatting, XSLT for transforming, XPath for searching, and XLink for linking. Much of the standards work

is under the auspices of the World Wide Web Consortium (W3C), an organization whose members include

Microsoft, Sun, IBM, and many academic and public institutions.

The W3C's mandate is to research and foster new technology for the Internet. That's a rather broad statement, but

if you visit their site at http://www.w3.org/ you'll see that they cover a lot of bases. The W3C doesn't create,

police, or license standards. Rather, they make recommendations that developers are encouraged, but not

required, to follow.

However, the system remains open enough to allow healthy dissent, such as the recent and interesting case of

XML Schema, a W3C standard that has generated controversy and competition. We'll examine this particular

story further in Chapter 3. It's strong enough to be taken seriously, but loose enough not to scare people away.

The recommendations are always available to the public.

Every developer should have working knowledge of XML, since it's the universal packing material for data, and

so many programs are all about crunching data. The rest of this chapter gives a quick introduction to XML for

developers.

2.2 Markup, Elements, and Structure

A markup language provides a way to embed instructions inside data to help a computer program process the

data. Most markup schemes, such as troff, TeX, and HTML, have instructions that are optimized for one

purpose, such as formatting the document to be printed or to be displayed on a computer screen. These

languages rely on a presentational description of data, which controls typeface, font size, color, or other media-

specific properties. Although such markup can result in nicely formatted documents, it can be like a prison for

your data, consigning it to one format forever; you won't be able to extract your data for other purposes without

significant work.

That's where XML comes in. It's a generic markup language that describes data according to its structure and

purpose, rather than with specific formatting instructions. The actual presentation information is stored

somewhere else, such as in a stylesheet. What's left is a functional description of the parts of your document,

which is suitable for many different kinds of processing. With proper use of XML, your document will be ready

for an unlimited variety of applications and purposes.

When a trusted body like the W3C makes a recommendation, it often has the effect of a law; many developers

begin to follow the recommendation upon its release, and developers who hope to write software that is compatible

with everyone else's (which is the whole point behind standards like XML) had better follow the recommendation as

well.

Perl and XML

age 14

Now let's review the basic components of XML. Its most important feature is the element. Elements are

encapsulated regions of data that serve a unique role in your document. For example, consider a typical book,

composed of a preface, chapters, appendixes, and an index. In XML, marking up each of these sections as a

unique element within the book would be appropriate. Elements may themselves be divided into other elements;

you might find the chapter's title, paragraphs, examples, and sections all marked up as elements. This division

continues as deeply as necessary, so even a paragraph can contain elements such as emphasized text, quotations,

and hypertext links.

Besides dividing text into a hierarchy of regions, elements associate a label and other properties with the data.

Every element has a name, or element type, usually describing its function in the document. Thus, a chapter

element could be called a "chapter" (or "chapt" or "ch" - whatever you fancy). An element can include other

information besides the type, using a name-value pair called an attribute. Together, an element's type and

attributes distinguish it from other elements in the document.

Example 2-1 shows a typical piece of XML.

Example 2-1. An XML fragment

<title>Things to Do This Week</title>

<item>clean the aquarium</item>

<item priority="important">save the whales</item>

</list>

This is, as you've probably guessed, a to-do list with three items and a title. Anyone who has worked with

HTML will recognize the markup. The pieces of text surrounded by angle brackets ("

<" and ">") are called tags,

and they act as bookends for elements. Every nonempty element must have both a start and end tag, each

containing the element type label. The start tag can optionally contain a number of attributes (name-value pairs

priority="important"). Thus, the markup is pretty clear and unambiguous - even a human can read it.

A human can read it, but more importantly, a computer program can read it very easily. The framers of XML

have taken great care to ensure that XML is easy to read by all XML processors, regardless of the types of tags

used or the context. If your markup follows all the proper syntactic rules, then the XML is absolutely

unambiguous. This makes processing it much easier, since you don't have to add code to handle unclear

situations.

Consider HTML, as it was originally defined (an application of XML's predecessor, SGML).

For certain

elements, it was acceptable to omit the end tag, and it's usually possible to tell from the context where an

element should end. Even so, making code robust enough to handle every ambiguous situation comes at the price

of complexity and inaccurate output from bad guessing. Now imagine how it would be if the same processor had

to handle any element type, not just the HTML elements. Generic XML processors can't make assumptions

about how elements should be arranged. An ambiguous situation, such as the omission of an end tag, would be

disastrous.

Any piece of XML can be represented in a diagram called a tree, a structure familiar to most programmers. At

the top (since trees in computer science grow upside down) is the root element. The elements that are contained

one level down branch from it. Each element may contain elements at still deeper levels, and so on, until you

reach the bottom, or "leaves" of the tree. The leaves consist of either data (text) or empty elements. An element

at any level can be thought of as the root of its own tree (or subtree, if you prefer to call it that). A tree diagram

of the previous example is shown in Figure 2-1 .

Currently, XHTML is an XML-legal variant of HTML that HTML authors are encouraged to adopt in support of

coming XML tools. XML enables different kinds of markup to be processed by the same programs (e.g., editors,

syntax-checkers, or formatters). HTML will soon be joined on the Web by such XML-derived languages as DocBook

and MathML.

Perl and XML

age 15

Figure 2-1. A to-do list represented as a tree structure

Besides the arboreal analogy, it's also useful to speak of XML genealogically. Here, we describe an element's

content (both data and elements) as its descendants, and the elements that contain it as its ancestors. In our list

example, each

<item> element is a child of the same parent, the <list> element, and a sibling of the others.

(We generally don't carry the terminology too far, as talking about third cousins twice-removed can make your

head hurt.) We will use both the tree and family terminology to describe element relationships throughout the

book.

2.3 Namespaces

It's sometimes useful to divide up your elements and attributes into groups, or namespaces . A namespace is to

an element somewhat as a surname is to a person. You may know three people named Mike, but no two of them

have the same last name. To illustrate this concept, look at the document in Example 2-2 .

Example 2-2. A document using namespaces

<?xml version="1.0"?>

<title>Fish and Bicycles: A Connection?</title>

<para>I have found a surprising relationship

of fish to bicycles, expressed by the equation

<equation>f = kb+n</equation>. The graph below illustrates

the data curve of my experiment:</para>

<graph:dimension>

<graph:axis>fish</graph:axis>

<graph:start>80</graph:start>

<graph:end>99</graph:end>

<graph:interval>1</graph:interval>

</graph:dimension>

<graph:dimension>

<graph:axis>bicycle</graph:axis>

<graph:start>0</graph:start>

<graph:end>1000</graph:end>

<graph:interval>50</graph:interval>

</graph:dimension>

<graph:equation>fish=0.01*bicycle+81.4</graph:equation>

</graph:chart>

</report>

Two namespaces are at play in this example. The first is the default namespace, where elements and attributes

lack a colon in their name. The elements whose names contain

graph: are from the "chartml" namespace

(something we just made up).

graph: is a namespace prefix that, when attached to an element or attribute name,

becomes a qualified name. The two

<equation> elements are completely different element types, with a

different role to play in the document. The one in the default namespace is used to format an equation literally,

and the one in the chart namespace helps a graphing program generate a curve.

Perl and XML

age 1

A namespace must always be declared in an element that contains the region where it will be used. This is done

with an attribute of the form

xmlns:prefix=URL, where prefix is the namespace prefix to be used (in this

case,

graph:) and URL is a unique identifier in the form of a URL or other resource identifier. Outside of the

scope of this element, the namespace is not recognized.

Besides keeping two like-named element types or attribute types apart, namespaces serve a vital function in

helping an XML processor format a document. Sometimes the change in namespace indicates that the default

formatter should be replaced with a kind that handles a specific kind of data, such as the graph in the example. In

other cases, a namespace is used to "bless" markup instructions to be treated as meta-markup, as in the case of

XSLT.

Namespaces are emerging as a useful part of the XML tool set. However, they can raise a problem when DTDs

are used. DTDs, as we will explain later, may contain declarations that restrict the kinds of elements that can be

used to finite sets. However, it can be difficult to apply namespaces to DTDs, which have no special facility for

resolving namespaces or knowing that elements and attributes that fall under a namespace (beyond the ever-

present default one) are defined according to some other XML application. It's difficult to know this information

partly because the notion of namespaces was added to XML long after the format of DTDs, which have been

around since the SGML days, was set in stone. Therefore, namespaces can be incompatible with some DTDs.

This problem is still unresolved, though not because of any lack of effort in the standards community.

Chapter 10 covers some practical issues that emerge when working with namespaces.

2.4 Spacing

You'l l notice in examples throughout this book that we indent elements and add spaces wherever it helps make

the code more readable to humans. Doing so is not unreasonable if you ever have to edit or inspect XML code

personally. Sometimes, however, this indentation can result in space that you don't want in your final product.

Since XML has a make-no-assumptions policy toward your data, it may seem that you're stuck with all that

space.

One solution is to make the XML processor smarter. Certain parsers can decide whether to pass space along to

the processing application.

They can determine from the element declarations in the DTD when space is only

there for readability and is not part of the content. Alternatively, you can instruct your processor to specialize in

a particular markup language and train it to treat some elements differently with respect to space.

When neither option applies to your problem, XML provides a way to let a document tell the processor when

space needs to be preserved. The reserved attribute

xml:space can be used in any element to specify whether

space should be kept as is or removed.

For example:

<address-label xml:space='preserve'>246 Marshmellow Ave.

Slumberville, MA

02149</address-label>

In this case, the characters used to break lines in the address are retained for all future processing. The other

setting for

xml:space is "default," which means that the XML processor has to decide what to do with extra

space.

A parser is a specialized XML handler that preprocesses a document for the rest of the program. Different parsers

have varying levels of "intelligence" when interpreting XML. We'll describe this topic in greater detail in Chapter 3.

We know that it's reserved because it has the special "xml" prefix. The XML standard defines special uses and

meanings for elements and attributes with this prefix.

剩余157页未读，继续阅读

songjasonstarlight

粉丝: 0
资源: 4

Perl与XML：编程黄金搭档，解析与应用指南

Perl.for.Oracle.DBAs

XML Processing with Perl, Python, and PHP (2002).pdf

Perl.Template.Toolkit

perl 将xml数据转为json格式

Perl Getopt and GetOptions

xml-libxml-2.0132

perl-Config-Perl-V-0.33

Can't locate Locale/gettext.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 / usr/share/perl5 .).

perl-libs-5.34.0

最新资源