초보자를위한 XML

HTML과 World Wide Web은 어디에나 있습니다. 그들의 편재성의 예로서, 나는 올해 부활절을 위해 중앙 아메리카에 갈 예정이며, 원한다면 웹 서핑을하고, 이메일을 읽고, 심지어 인터넷 카페에서 온라인 뱅킹을 할 수있을 것입니다. 안티구아 과테말라 및 벨리즈 시티. (하지만 그렇게하면 야자 나무와 럼이 가득한 코코넛과 데이트하는 데 시간이 걸리기 때문에 그렇게 할 생각은 없습니다.)

그럼에도 불구하고 HTML의 편재성과 인기에도 불구하고 할 수있는 일이 극히 제한적입니다. 비공식 문서를 배포하는 것은 좋지만 HTML은 이제 설계되지 않은 작업을 수행하는 데 사용되고 있습니다. HTML에서 강력하고 유연하며 상호 운용 가능한 데이터 시스템을 설계하려는 것은 쇠톱과 납땜 인두를 사용하여 항공 모함을 구축하려는 것과 같습니다. 도구 (HTML 및 HTTP)는 작업에 적합하지 않습니다.

좋은 소식은 HTML의 많은 한계가 XML (Extensible Markup Language)에서 극복되었다는 것입니다. XML은 HTML을 이해하는 사람이라면 누구나 쉽게 이해할 수 있지만 훨씬 더 강력합니다. 단순한 마크 업 언어 이상으로 XML은 새로운 마크 업 언어를 정의하는 데 사용되는 언어 인 메타 언어입니다. XML을 사용하면 응용 프로그램이나 도메인을 위해 특별히 제작 된 언어를 만들 수 있습니다.

XML은 HTML을 대체하는 것이 아니라 보완합니다. HTML이 데이터 형식화 및 표시에 사용되는 반면, XML은 데이터의 상황에 맞는 의미를 나타냅니다.

이 기사에서는 마크 업 언어의 역사와 XML이 어떻게 생겨 났는지 설명합니다. HTML의 샘플 데이터를 살펴보고 점진적으로 XML로 이동하여 데이터를 표현하는 우수한 방법을 제공하는 이유를 설명합니다. 사용자 지정 마크 업 언어를 만들어야하는 이유를 살펴보고 그 방법을 알려 드리겠습니다. XML 표기법의 기본 사항과 두 가지 유형의 스타일 언어로 XML을 표시하는 방법을 다룰 것입니다. 그런 다음 문서를 객체로 조작 (또는 보는 방식에 따라 객체 구조를 문서로 조작)하는 강력한 도구 인 Document Object Model에 대해 알아 보겠습니다. 이러한 새로운 개념을 실험하는 데 유용한 무료 프로그램에 대한 포인터와 함께 XML 문서에서 정보를 추출하는 Java 프로그램을 작성하는 방법을 살펴 보겠습니다. 마지막으로 우리는XML과 Java를 기반으로하는 핵심 기술 전략을 기반으로하는 인터넷 회사를 살펴 보겠습니다.

XML이 적합합니까?

이 기사는 XML에 관심이있는 모든 사람을 위해 작성되었지만 XML JavaBeans 의 JavaWorld 시리즈와 특별한 관계가 있습니다. (관련 기사에 대한 링크는 참고 자료를 참조하십시오.) 해당 시리즈를 읽었지만 "이해하지 않는"경우이 기사는 Bean과 함께 XML을 사용하는 방법을 설명해야합니다. 당신이 경우에 하는 그것을 받고는 그대로 거기에 주제를 다루고 있기 때문에,이 문서는 XML 자바 빈즈 시리즈 완벽한 동반자 조각의 역할을한다. 그리고 기대할 수있는 XML JavaBeans 기사를 가지고있는 운이 좋은 몇 안되는 사람이라면 먼저 현재 기사를 소개 자료로 읽는 것이 좋습니다.

Java에 대한 참고 사항

컴퓨터 세계에는 최근 XML 활동이 너무 많아서이 정도 길이의 기사라도 표면을 훑어 볼 수 있습니다. 그러나이 기사의 요점은 Java 프로그램 설계에서 XML을 사용하는 데 필요한 컨텍스트를 제공하는 것입니다. 이 기사는 또한 많은 Java 프로그래머가 이러한 환경에서 작업하기 때문에 XML이 기존 웹 기술과 함께 작동하는 방법을 다룹니다.

XML은 인터넷 및 Java 프로그래밍을 브라우저가 아닌 이식 가능한 기능으로 엽니 다. XML은 Java가 플랫폼에서 프로그램 동작을 해제하는 것과 같은 방식으로 브라우저에서 인터넷 콘텐츠를 해제합니다. XML은 실제 응용 프로그램에서 인터넷 콘텐츠를 사용할 수 있도록합니다.

Java는 XML을 사용하기위한 탁월한 플랫폼이며 XML은 Java 애플리케이션을위한 뛰어난 데이터 표현입니다. XML에 대한 Java의 강점을 몇 가지 지적하겠습니다.

역사 수업부터 시작하겠습니다.

마크 업 언어의 기원

우리 모두가 알고 좋아하는 HTML (어쨌든 우리가 알고있는)은 원래 제네바의 CERN ( le Conseil Européen pour la Recherche Nucléaire 또는 유럽 입자 물리학 연구소)의 Tim Berners-Lee가 물리학 전문가 ( 그리고 심지어 비 바보) 서로 의사 소통합니다. HTML은 CERN 내에서 1990 년 12 월에 출시되었으며 1991 년 여름에 나머지 사람들에게 공개되었습니다. CERN과 Berners-Lee는 인터넷 공유 및 즐기기의 오래된 전통에 따라 HTML, HTTP 및 URL에 대한 사양을 제공했습니다.

Berners-Lee는 표준 일반화 마크 업 언어 인 SGML로 HTML을 정의했습니다. XML과 마찬가지로 SGML은 다른 언어를 정의하는 데 사용되는 언어 인 메타 언어입니다. 이렇게 정의 된 각 언어 를 SGML 의 응용 프로그램 이라고합니다 . HTML은 SGML의 응용 프로그램입니다.

SGML은 1960 년대 후반에 주로 IBM에서 텍스트 문서 표현에 대해 수행 한 연구에서 나왔습니다. IBM은 SGML의 이전 언어 인 GML ( "General Markup Language")을 만들었으며 1978 년 ANSI (American National Standards Institute)는 SGML의 첫 번째 버전을 만들었습니다. 첫 번째 표준은 1983 년에 발표되었고 표준 초안은 1985 년에 발표되었으며 첫 번째 표준은 1986 년에 발표되었습니다. 흥미롭게도 첫 번째 SGML 표준은 CERN에서 Anders Berglund가 개발 한 SGML 시스템을 사용하여 발표되었습니다. 우리는 HTML과 웹을 보았습니다.

SGML은 대규모 항공 우주, 자동차 및 통신 회사와 같은 대규모 산업 및 정부에서 널리 사용됩니다. SGML은 미국 국방부 및 국세청에서 문서 표준으로 사용됩니다. (미국 이외의 독자의 경우 IRS가 세금 담당자입니다.)

알버트 아인슈타인은 모든 것이 가능한 한 단순해야하며 더 단순해서는 안된다고 말했습니다. SGML이 더 많은 곳에서 발견되지 않는 이유는 매우 정교하고 복잡하기 때문입니다. 그리고 어디에서나 찾을 수있는 HTML은 매우 간단합니다. 많은 응용 프로그램의 경우 너무 간단합니다.

HTML : 모든 형식 및 내용 없음

HTML은 제목, 제목, 캡션, 글꼴 등 문서를 "대화"하도록 설계된 언어입니다. 문서 구조 및 프리젠 테이션 지향적입니다.

물론 아티스트와 해커는 HTML이라는 비교적 지루한 도구를 사용하여 기적을 이룰 수있었습니다. 그러나 HTML에는 유연하고 강력하며 진화적인 정보 시스템을 설계하는 데 적합하지 않은 심각한 단점이 있습니다. 다음은 몇 가지 주요 불만 사항입니다.

  • HTML은 확장 할 수 없습니다.

    확장 가능한 마크 업 언어를 사용하면 응용 프로그램 개발자가 응용 프로그램 별 상황에 맞게 사용자 정의 태그를 정의 할 수 있습니다. 600 파운드의 고릴라가 아니라면 (그때는 아닐 수도 있음) 모든 브라우저 제조업체가 애플리케이션에 필요한 모든 마크 업 태그를 구현하도록 요구할 수 없습니다. 따라서 대형 브라우저 제조업체 또는 W3C (World Wide Web Consortium)가 제공 할 수있는 기능에 갇혀 있습니다. 우리에게 필요한 것은 브라우저 제조업체에 전화하지 않고도 자체 마크 업 태그를 만들 수있는 언어입니다.

  • HTML은 매우 디스플레이 중심적입니다.

    HTML은 정확한 서식이나 변형 제어가 많이 필요하지 않는 한 (악취가 나는 경우) 표시 목적에 적합한 언어입니다. HTML은 문서 논리 구조 (제목, 단락 등)와 프레젠테이션 태그 (굵게, 이미지 정렬 등)의 혼합을 나타냅니다. 거의 모든 HTML 태그가 브라우저에 정보를 표시하는 방법과 관련이 있기 때문에 HTML은 데이터 복제 또는 애플리케이션 서비스와 같은 다른 일반적인 네트워크 애플리케이션에는 쓸모가 없습니다. 이러한 공통 기능을 디스플레이와 통합하는 방법이 필요하므로 데이터를 검색하는 데 사용되는 동일한 서버가 예를 들어 엔터프라이즈 비즈니스 기능을 수행하고 레거시 시스템과 상호 운용 될 수 있습니다.

  • HTML은 일반적으로 직접 재사용 할 수 없습니다.

    Creating documents in word-processors and then exporting them as HTML is somewhat automated but still requires, at the very least, some tweaking of the output in order to achieve acceptable results. If the data from which the document was produced change, the entire HTML translation needs to be redone. Web sites that show the current weather around the globe, around the clock, usually handle this automatic reformatting very well. The content and the presentation style of the document are separated, because the system designers understand that their content (the temperatures, forecasts, and so on) changes constantly. What we need is a way to specify data presentation in terms of structure, so that when data are updated, the formatting can be "reapplied" consistently and easily.

  • HTML only provides one 'view' of data

    It's difficult to write HTML that displays the same data in different ways based on user requests. Dynamic HTML is a start, but it requires an enormous amount of scripting and isn't a general solution to this problem. (Dynamic HTML is discussed in more detail below.) What we need is a way to get all the information we may want to browse at once, and look at it in various ways on the client.

  • HTML has little or no semantic structure

    Most Web applications would benefit from an ability to represent data by meaning rather than by layout. For example, it can be very difficult to find what you're looking for on the Internet, because there's no indication of the meaning of the data in HTML files (aside from META tags, which are usually misleading). Type

    red

    into a search engine, and you'll get links to Red Skelton, red herring, red snapper, the red scare, Red Letter Day, and probably a page or two of "Books I've Red." HTML has no way to specify what a particular page item means. A more useful markup language would represent information in terms of its meaning. What we need is a language that tells us not how to

    display

    information, but rather, what a given block of information

    is

    so we know what to do with it.

SGML has none of these weaknesses, but in order to be general, it's hair-tearingly complex (at least in its complete form). The language used to format SGML (its "style language"), called DSSSL (Document Style Semantics and Specification Language), is extremely powerful but difficult to use. How do we get a language that's roughly as easy to use as HTML but has most of the power of SGML?

Origins of XML

As the Web exploded in popularity and people all over the world began learning about HTML, they fairly quickly started running into the limitations outlined above. Heavy-metal SGML wonks, who had been working with SGML for years in relative obscurity, suddenly found that everyday people had some understanding of the concept of markup (that is, HTML). SGML experts began to consider the possibility of using SGML on the Web directly, instead of using just one application of it (again, HTML). At the same time, they knew that SGML, while powerful, was simply too complex for most people to use.

In the summer of 1996, Jon Bosak (currently online information technology architect at Sun Microsystems) convinced the W3C to let him form a committee on using SGML on the Web. He created a high-powered team of muckety-mucks from the SGML world. By November of that year, these folks had created the beginnings of a simplified form of SGML that incorporated tried-and-true features of SGML but with reduced complexity. This was, and is, XML.

In March 1997, Bosak released his landmark paper, "XML, Java and the Future of the Web" (see Resources). Now, two years later (a very long time in the life of the Web), Bosak's short paper is still a good, if dated, introduction to why using XML is such an excellent idea.

SGML was created for general document structuring, and HTML was created as an application of SGML for Web documents. XML is a simplification of SGML for general Web use.

An XML conceptual example

All this talk of "inventing your own tags" is pretty foggy: What kind of tags would a developer want to invent and how would the resulting XML be used? In this section, we'll go over an example that compares and contrasts information representation in HTML and XML. In a later section ("XSL: I like your style") we'll go over XML display.

First, we'll take an example of a recipe, and display it as one possible HTML document. Then, we'll redo the example in XML and discuss what that buys us.

HTML example

Take a look at the little chunk of HTML in Listing 1:

   Lime Jello Marshmallow Cottage Cheese Surprise   

Lime Jello Marshmallow Cottage Cheese Surprise

My grandma's favorite (may she rest in peace).

Ingredients

Qty Units Item
1 box lime gelatin
500 g multicolored tiny marshmallows
500 ml cottage cheese
dash Tabasco sauce (optional)

Instructions

  1. Prepare lime gelatin according to package instructions...

Listing 1. Some HTML

(A printable version of this listing can be found at example.html.)

Looking at the HTML code in Listing 1, it's probably clear to just about anyone that this is a recipe for something (something awful, but a recipe nonetheless). In a browser, our HTML produces something like this:

Lime Jello Marshmallow Cottage Cheese Surprise

My grandma's favorite (may she rest in peace).

Ingredients

Qty Units Item
1 box lime gelatin
500 g multicolored tiny marshmallows
500 ml Cottage cheese
  dash Tabasco sauce (optional)

Instructions

  1. Prepare lime gelatin according to package instructions...

Listing 2. What the HTML in Listing 1 looks like in a browser

Now, there are a number of advantages to representing this recipe in HTML, as follows:

  • It's fairly readable. The markup may be a little cryptic, but if it's laid out properly it's pretty easy to follow.

  • The HTML can be displayed by just about any HTML browser, even one without graphics capability. That's an important point: The display is browser-independent. If there were a photo of the results of making this recipe (and one certainly hopes there isn't), it would show up in a graphical browser but not in a text browser.

  • You could use a cascading style sheet (CSS -- we'll talk a bit about those below) for general control over formatting.

There's one major problem with HTML as a data format, however. The meaning of the various pieces of data in the document is lost. It's really hard to take general HTML and figure out what the data in the HTML mean. The fact that there's an of this recipe with a (quantity) of 500 ml () of cottage cheese would be very hard to extract from this document in a way that's generally meaningful.

Now, the idea of data in an HTML document meaning something may be a bit hard to grasp. Web pages are fine for the human reader, but if a program is going to process a document, it requires unambiguous definitions of what the tags mean. For instance, the tag in an HTML document encloses the title of the document. That's what the tag means, and it doesn't mean anything else. Similarly, an HTML tag means "table row," but that's of little use if your program is trying to read recipes in order to, say, create a shopping list. How could a program find a list of ingredients from a Web page formatted in HTML?

Sure, you could write a program that grabs the headers out of the document, reads the table column headers, figures out the quantities and units of each ingredient, and so on. The problem is, everyone formats recipes differently. What if you're trying to get this information from, say, the Julia Childs Web site, and she keeps messing around with the formatting? If Julia changes the order of the columns or stops using tables, she'll break your program! (Though it has to be said: If Julia starts publishing recipes like this, she may want to think about changing careers.)

Now, imagine that this recipe page came from data in a database and you'd like to be able to ship this data around. Maybe you'd like to add it to your huge recipe database at home, where you can search and use it however you like. Unfortunately, your input is HTML, so you'll need a program that can read this HTML, figure out what all the "Ingredients," "Instructions," "Units," and so forth are, and then import them to your database. That's a lot of work. Especially since all of that semantic information -- again, the meaning of the data -- existed in that original database but were obscured in the process of being transformed into HTML.

Now, imagine you could invent your own custom language for describing recipes. Instead of describing how the recipe was to be displayed, you'd describe the information structure in the recipe: how each piece of information would relate to the other pieces.

XML example

Let's just make up a markup language for describing recipes, and rewrite our recipe in that language, as in Listing 3.

  Lime Jello Marshmallow Cottage Cheese Surprise  My grandma's favorite (may she rest in peace).    1 lime gelatin   500 multicolored tiny marshmallows   500 Cottage cheese    Tabasco sauce     Prepare lime gelatin according to package instructions     

Listing 3. A custom markup language for recipes

It will come as little surprise to you, being the astute reader you are, that this recipe in its new format is actually an XML document. Maybe the fact that the file started with the odd header


  

gave it away; in fact, every XML file should begin with this header. We've simply invented markup tags that have a particular meaning; for example, "An is a (quantity in specified units) of a single , which is possibly optional." Our XML document describes the information in the recipe in terms of recipes, instead of in terms of how to display the recipe (as in HTML). The semantics, or meaning of the information, is maintained in XML because that's what the tag set was designed to do.

Notes on notation

It's important to get some nomenclature straight. In Figure 1, you see a start tag, which begins an enclosed area of text, known as an Item, according to the tag name. As in HTML, XML tags may include a list of attributes (consisting of an attribute name and an attribute value.) The Item defined by the tag ends with the end tag.

Not every tag encloses text. In HTML, the

tag means "line break" and contains no text. In XML, such elements aren't allowed. Instead, XML has empty tags, denoted by a slash before the final right-angle bracket in the tag. Figure 2 shows an empty tag from our XML recipe. Note that empty tags may have attributes. This empty tag example is standard XML shorthand for .

In addition to these notational differences from HTML, the structural rules of XML are more strict. Every XML document must be well-formed. What does that mean? Read on!

Ooh-la-la! Well-formed XML

The concept of well-formedness comes from mathematics: It's possible to write mathematical expressions that don't mean anything. For example, the expression

2 ( + + 5 (=) 9 > 7

looks (sort of) like math, but it isn't math because it doesn't follow the notational and structural rules for a mathematical expression (not on this planet, at least). In other words, the "expression" above isn't well-formed. Mathematical expressions must be well-formed before you can do anything useful with them, because expressions that aren't well-formed are meaningless.

A well-formed XML document is simply one that follows all of the notational and structural rules for XML. Programs that intend to process XML should reject any input XML that doesn't follow the rules for being well-formed. The most important of these rules are as follows: