XML을 사용하는 좋은 습관 열 가지

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 초급

Martin Brown, 개발자 겸 필자, 자유기고가

2008 년 9 월 23 일

이 기사에서는 XML을 좀 더 효율적이고 효과적으로 사용하는 좋은 습관 열 가지를 소개합니다. 이 기사에서 소개하는 습관을 익히면 XML을 사용할 때 오류가 적어지고 생산성이 높아집니다.

개요

XML과 XML이 제공하는 유연성(flexibility)과 상호운용성(interoperability)을 좋아한다면, 한 걸음 더 나가 XML과 XML 도구를 좀 더 효과적이고 효율적으로 사용하는 방법을 익히라고 권한다. XML을 올바로 사용하는 습관을 익히면 XML 문서와 응용 프로그램을 사용하기가 훨씬 쉬워진다.

위로

좋은 습관 열 가지

자주 사용하는 약어 DOM: Document Object Model DTD: Document Type Definition HTML: Hypertext Markup Language IDE: Integrated Development Environment SAX: Simple API for XML XSD: XML Schema Definition XML: Extensible Markup Language XSLT: Extensible Stylesheet Language Transformations

다음은 XML을 사용하는 좋은 습관 열 가지다.

1. XML과 인코딩을 정의하라
2. DTD 또는 XSD를 사용하라
3. 항상 검증하라
4. 때로는 검증으로 부족하다
5. 엘리먼트냐 속성이냐
6. XPath를 활용해 정보를 찾자
7. 정보 인출을 위해 반드시 구문분석기를 사용할 필요는 없다
8. SAX가 DOM보다 나은 경우
9. DOM이 SAX보다 나은 경우
10. 좋은 XML 편집기를 사용하라

위로

XML과 인코딩을 정의하라

급하게 XML 문서를 생성할 때 간단히 기본 구조만 잡고는 XML 문서 요구사항을 빼먹기 십상이다. 예를 들어, XML 선언부(XML declaration)나 자료 인코딩 유형(data encoding type)을 생략하는 경우가 있다.

Listing 1은 기본 구조만 정의한 XML 문서다.

                
<phrases>
  <phrase lang="en">Hello</phrase>
  <phrase lang="it">Buongiorno</phrase>
  <phrase lang="fr">Salut!</phrase>
</phrases>

사람은 문서를 딱 보면 XML인지 안다. 하지만 컴퓨터는 즉석에서 문서 유형을 판단하기 어렵다. 그래서 파일 첫 행에 XML 선언부를 추가하여 문서가 XML 형식이라는 사실을 명시한다. 다음은 문서가 XML이라는 사실을 명시하는 행이다. 여기서 XML 선언부는 버전 번호와 자료 인코딩 방식도 포함한다. 예를 들면 다음과 같다.

<?xml version="1.0" encoding="us-ascii"?>

인코딩 방식을 정확히 선언하도록 주의한다. XML 구문분석기는 이 인코딩 방식을 사용하여 XML 문서에서 개별 문자를 읽어들인다. 예를 들어, Listing 1을 정의한 XML 문서에 러시아어 엔티티를 추가하면 문제가 생긴다. 현재 지정한 인코딩 방식(us-ascii)이 러시아어 hello에 들어가는 특수문자 집합을 지원하지 못하기 때문이다.

인코딩 방식을 잘못 선언하면 XML 구문분석기가 문서를 잘못 분석할 가능성이 생긴다. 예를 들어, 멀티바이트 문자를 한 바이트씩 읽어 해석하면 당연히 자료를 망가뜨려 잘못된 결과를 얻는다.

위로

DTD 또는 XSD를 사용하라

일단 XML 선언부를 추가했다면 이제 DTD나 XSD로 유효한 XML 문서 구조를 정의할 차례다. XML 구문분석기는 DTD나 XSD를 토대로 XML 문서 내용이 유효한 구조에 맞아 떨어지는지 점검하고 확인한다.

예를 들어, 연락처 데이터베이스에서 사용할 XML 구조를 간단히 정의하자. XML 구조는 연락처 이름, 주소, 전화번호 등을 포함한다. DTD로 구조를 정의하면 XML 문서에서 구조 내 각 연락처가 DTD에서 기술한 레이아웃과 일치하는지 확인할 수 있다.

예를 들어, Listing 2는 연락처 데이터베이스에서 사용할 DTD다.

                
<!ELEMENT phone (#PCDATA)>
<!ATTLIST phone type (home | work | mobile) #REQUIRED>
<!ELEMENT contact (#PCDATA | name | phone | address)*>
<!ELEMENT contacts (#PCDATA | contact)*>
<!ELEMENT country (#PCDATA)>
<!ELEMENT road (#PCDATA)>
<!ELEMENT address (#PCDATA | road | city | state | postcode | country)*>
<!ATTLIST address type (home | work) #REQUIRED>
<!ELEMENT state (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT postcode (#PCDATA)>
<!ELEMENT city (#PCDATA)>

이 DTD는 연락처를 기술하는 엘리먼트와 속성과 속성 값(그리고 속성이 지원하는 값)을 정의한다. Listing 2에서 보듯이, phone 엘리먼트는 type이라는 속성이 있다. address와 address 내 컴포넌트에도 속성이 있다.

DTD를 정의하면 XML 문서 구조를 검증해 문제를 찾아내기 쉬워진다. XML 편집기는 DTD를 토대로 편집 내용을 자동으로 완성하는 기능도 제공한다.

XSD(혹은 스키마)는 DTD와 거의 비슷한 기능을 제공하지만, 몇 가지 다른 측면에서 유용하다. 예를 들어, 일부 XML 편집기는 자동 완성 기능에 DTD를 요구하는 반면, 스키마를 사용하면 실제 문서 구조를 설계하기가 훨씬 편리해진다. DTD를 사용할지 XSD를 사용할지 여부는 개발자가 처한 상황에 달렸다.

위로

항상 검증하라

Listing 3을 주의깊게 살펴보자. 문제가 보이는가?

                
<contacts>
  <contact>
    <name>Martin</name>
    <phone type="home">123 456 7890</phone>
    <phone type="mobile">123 456 7890</phone>
    <phone type="work">123 456 7890</phone>
    <address type="home">
      <road>Home road</road>
      <city>Home city</city>
      <state>Home state</state>
      <zipcode>12434</zipcode>
      <country>USA</country>
    </address>
  </contact>
  <contact>
    <name>Sharon</name>
    <phone type="work">234 567 8901</phone>
    <phone>234 567 8901</phone>
    <address type="home">
      <road>Other home road</road>
      <city>Other city</city>
      <state>Other state</state>
      <zipcode>39487</zipcode>
      <country>USA</country>
    </address>
    <address type="work>
      <road>Work building, work road</road>
      <city>Work city</city>
      <state>Work state</state>
      <zipcode>12347</zipcode>
      <country>USA</country>
    </address>
  </contact>
</contacts>

눈으로 훑어서는 문제를 찾기가 쉽지 않다. 하지만 xmllint를 돌리면 Listing 4와 같은 결과를 금방 얻는다. 참고로, xmllint는 XML 문서 내용과 구조를 검증하는 무료 도구다.

                
$ xmllint contacts.xml 
contacts.xml:27: parser error : Unescaped '<' not allowed in attributes values
      <road>Work building, work road</road>
      ^
contacts.xml:27: parser error : attributes construct error
      <road>Work building, work road</road>
      ^
contacts.xml:27: parser error : Couldn't find end of Start Tag address line 26
      <road>Work building, work road</road>
      ^
contacts.xml:32: parser error : Opening and ending tag mismatch: contact line 15 
                                                       and address
    </address>
              ^
contacts.xml:33: parser error : Opening and ending tag mismatch: contacts line 1 
                                                       and contact
  </contact>
            ^
contacts.xml:34: parser error : Extra content at the end of the document
</contacts>

실제 문제에 비하면 결과가 아주 복잡해 보인다(실제 문제는 속성 하나를 제대로 닫지 않아서 생긴다). 하지만 위 결과는 문제를 찾아내기에 좋은 출발점을 제공한다.

게다가 xmllint는 진단 방법과 결과를 선택하는 다양한 명령행 옵션도 제공한다. 가장 유용한 옵션 중 하나가 --noout 옵션이다. 이 옵션을 지정하면 xmllint가 XML 문서를 분석하는 과정에서 XML 문서 내용을 다시 출력하지 않는다. 간단한 파일에서는 XML 내용을 출력해도 문제가 없지만, 긴 파일에서는 결과를 이해하기 힘들어진다.

DTD를 사용한다면 --postvalid 옵션을 사용한다. 이 옵션을 지정하면 xmllint는 XML 문서가 DTD에 맞는지 검사한다. 구체적으로는 XML 문서가 유효한 동시에 DTD에서 정의하는 구조에 일치하는지도 검사한다. Listing 3에서 속성 정의 오류를 수정한 후 Listing 2에서 정의한 DTD로 xmllint를 돌리면 다른 오류가 출력된다. 자세한 내용은 Listing 5를 참조한다.

                
$ xmllint --noout --postvalid contacts.xml 
contacts.xml:9: element address: validity error : Element zipcode is not declared 
                            in address list of possible children
contacts.xml:21: element address: validity error : Element zipcode is not declared 
                            in address list of possible children
contacts.xml:28: element address: validity error : Element zipcode is not declared 
                            in address list of possible children
Document contacts.xml does not validate

이렇듯 xmllint는 XML 문서 구조를 빠르고 간편하게 검증한다. xmllint는 libxml2 툴킷에 포함되며, libxml2 툴킷은 리눅스, 유닉스(UNIX®), 맥 OS X에 기본적으로 들어있다. 윈도(Windows®) 플랫폼에서는 별도로 툴킷을 내려받아야 한다. xmllint와 libxml2에 관한 자세한 내용은 참고자료에서 제공한다.

위로

때로는 검증으로 부족하다

xmllint나 그와 비슷한 도구는 XML 문서 내용을 검증하기에 멋진 방법이다. 특히 DTD를 사용하는 경우라면 더욱 편리하다. 하지만 이 방법이 모든 문제를 해결하지는 못한다. 예를 들어, XML 엘리먼트 값을 고려해 보자.

DTD나 XSD는 속성 값을 명시적으로 정의한다. 즉, DTD나 XSD에서 정의하는 옵션만 속성 값으로 사용할 수 있다. 하지만 엘리먼트 내용은 이런 방식으로 통제하거나 제한하기 불가능하다.

예를 들어, 연락처 예제에서 전화번호는 숫자와 공백으로 이루어진다. 하지만 사용자가 전화번호 엘리먼트 값으로 영문자를 추가해도 막을 방법이 없다. xmllint는 이러한 오류를 감지하지 못한다. XML 편집기나 다른 XML 도구도 이러한 오류를 찾아내거나 해결하지 못한다. 응용 프로그램이 오류를 일으킨 후에야 표준이 아닌 자료 유형 사용이라는 문제를 발견할 가능성이 높다.

간단히 말해, XML 검증은 구조가 올바른지만 검증할 뿐 자료가 올바른지는 검증하지 못한다.

가장 간단한 해결책은 XML 문서를 읽어들이는 구문분석기를 직접 구현하여 자료를 검증하는 방법이다. 그렇다고 지나치게 꼼꼼히 검증할 필요는 없다. 응용 프로그램이 요구하는 조건만 만족하면 충분하다.

위로

엘리먼트냐 속성이냐

XML 문서에서 정보를 기술할 때 엘리먼트와 속성 중 무엇을 사용하는 편이 좋을까? 의견이 분분하다.

일반적으로는 파일 내부에서 엘리먼트를 사용해 정보를 기술하는 편이 낫다. 즉, 자료를 태그 사이에 정의하는 편이 낫다. 속성은 기술하고자 하는 자료에 조건을 추가할 때 사용해야 한다.

엘리먼트와 속성 모두 제약이 존재한다. 예를 들어, 속성은 태그 내에서 반복적으로 정의하지 못한다. 반면, 엘리먼트는 반복적으로 정의해도 괜찮다. 엘리먼트가 속성보다 편리하고 실용적인 점 중 하나다. 반대로, 엘리먼트로는 자료에 조건을 추가하기가 다소 까다롭다.

위 연락처 예제에서 전화번호 엘리먼트와 속성은 이러한 장단점을 잘 드러낸다. Listing 6에서 보듯이, 전화번호(phone) 엘리먼트는 조건으로 유형(type)이라는 속성을 지정한다. 유형은 회사(work), 집(home), 휴대전화(mobile) 중 하나다.

                
<phone type="home">123 456 7890</phone>
<phone type="mobile">123 456 7890</phone>
<phone type="work">123 456 7890</phone>
 

위 구조에서는 (속성을 무시한 채) 전화번호 전부를 찾거나 (속성을 사용하여) 특정한 전화번호 유형을 찾기가 쉽다.

Listing 7은 엘리먼트만 사용하여 기술한 구조다. Listing 6과 비교해 보자.

                
<phone>
  <type>home</type>
  <number>123 456 7890</number>
</phone>
<phone>
  <type>mobile</type>
  <number>123 456 7890</number>
</phone>
<phone>
  <type>work</type>
  <number>123 456 7890</number>
</phone>

위에서 보듯이, 숲에서 나무를 가려내기가 쉽지 않다. 이론상으로는 XML 구문분석기나 적절한 XPath로 원하는 정보를 추출할 수 있지만, 속성을 사용하는 경우와 비교하여 문서 가독성만 떨어질 뿐 사실상 얻어지는 장점은 거의 없다.

위로

XPath를 활용해 정보를 찾자

XML 문서를 다룰 때, 원하는 정보를 정확히 찾아내기란 상당히 복잡하다. 물론, XML 구문분석기를 직접 작성해 필요한 정보를 추출하는 방법도 있지만, 아주 작은 정보를 재빨리 찾아낼 목적이라면 자칫 배보다 배꼽이 더 커진다.

예를 들어, 연락처 XML 파일에서 모든 국가를 추출해 연락자 분포를 살펴보려고 한다. 이 때 XPath를 사용하면 국가 목록을 쉽게 추출할 수 있다.

XPath는 XML 문서 구조를 질의 일부로 사용하여 XML 문서에서 자료를 추출한다. 구체적으로는 원하는 엘리먼트까지 가는 경로를 지정한다. 예를 들어, 다음 XPath 조회는 연락처 XML 파일에서 국가 목록을 추출한다.

$ xpath contacts.xml '//contact/address/country'

XML 문서는 다음과 같이 분석된다.

• 첫 슬래시 두 개(//)는 문서 내부에서 특정한 엘리먼트(contact)를 찾는다.
• 다음 슬래시와 엘리먼트 이름은 contact 엘리먼트 내에서 찾을 엘리먼트(address)를 지정한다. 즉, contact 엘리먼트 내부에서 address 엘리먼트를 찾는다.
• 마지막 슬래시도 이런 과정을 반복한다. 최종적으로 country 엘리먼트를 찾는다.

위 예제는 주소 유형을 지정하지 않는다. 따라서 모든 주소를 추출한다. XPath 질의 결과는 Listing 8과 같다.

                
$ xpath contacts.xml '//contact/address/country' 
Found 3 nodes:
-- NODE --
<country>USA</country>-- NODE --
<country>USA</country>-- NODE --
<country>USA</country>

좀 더 구체적인 자료가 필요하다면 엘리먼트 값이나 속성 값을 지정해 결과 범위를 좁혀도 된다. 예를 들어, 휴대전화 번호만 추출하려면 속성 유형과 값을 지정한다. Listing 9에서 보듯이, @ 기호 다음에 찾으려는 속성 이름을 지정한 후 속성 값을 지정하면 된다.

                
$ xpath contacts.xml '//contact/phone[@type="mobile"]' 
Found 1 nodes:
-- NODE --
<phone type="mobile">123 456 7890</phone>

Listing 8과 Listing 9는 명령행 도구를 사용한다. 많은 XML 툴킷은 XPath로 엘리먼트를 지정하는 방법을 제공하므로, 별도로 구문분석기를 사용하지 않고도 응용 프로그램에서 XPath를 사용해 원하는 정보를 추출할 수 있다.

위로

정보 인출을 위해 반드시 구문분석기를 사용할 필요는 없다

이상하게 들리겠지만 반드시 SAX, DOM, XPath, XQuery 등을 사용하여 XML 문서에서 정보를 추출할 필요는 없다.

XML 파일은 구조화된 형식으로 정보를 포함한다. 구조화된 형식 그대로 정보가 필요할 때도 있지만, 간단한 정보 하나만 필요한 경우도 흔하다. 이 때는 좀 더 간단한 방법이 더 효율적이다.

예를 들어 grep, 펄 등을 사용하면 XML 문서를 구문분석하지 않고도 간단한 정보를 추출할 수 있다.

Listing 10은 grep을 사용하여 전화번호를 추출한다.

                
$ grep '<phone' contacts.xml

<phone type="home">123 456 7890</phone>
<phone type="mobile">123 456 7890</phone>
<phone type="work">123 456 7890</phone>
<phone type="work">234 567 8901</phone>
<phone>234 567 8901</phone>

Listing 10은 문서 내용이나 구조를 염려하지 않고 원하는 정보를 간단히 추출한다.

간단한 정보를 재빨리 찾으려면 위와 같이 단순한 검색 기술을 추천한다. 전통적인 구문분석 기법에 비해 부하는 적으면서 효과는 같다.

위로

DOM보다 SAX가 나은 경우

XML 문서를 분석하는 구문분석기를 직접 구현할 때 SAX 기반 프로세서를 사용할지, DOM 기반 프로세서를 사용할지 결정하기가 쉽지 않다.

가장 쉽게 결정하는 방법으로, 문서의 복잡도와 정보의 사용 목적을 고려한다. 문서가 크거나 문서를 변환할 생각이라면 SAX가 낫다.

SAX 파서는 문서를 엘리먼트 단위로 분석하며, 엘리먼트를 식별한 직후에 메서드나 함수를 호출한다. XML 문서를 다른 형식으로 변환한다면 (예를 들어, XML을 HTML로 변환한다면) SAX가 가장 효율적이다. 문서 전체를 메모리로 읽어들일 필요 없이 엘리먼트와 구조를 인식하는 즉시 변환을 수행할 수 있다.

반면, 구조를 저장하거나 기록하려는 경우에는 SAX가 적합하지 못하다. 또는 문서 전체를 이해한 다음에 문서에서 특정 정보를 추출하려는 경우에도 (예를 들어, 전체 문서에서 연락처 하나만 찾는 경우에도) 마찬가지다. 이 때는 XML 문서 전체를 읽어 자료 구조를 판독한 후 (필요에 따라) 엘리먼트를 출력하는 복잡한 처리 과정을 구현해야 한다.

위로

DOM이 SAX보다 나은 경우

DOM은 문서와 구조 전체를 메모리로 읽어들인다. 따라서 응용 프로그램 내에서 XML 문서 구조 전체를 참조하고 사용할 수 있다. 예를 들어, 앞서 보았던 연락처 예제에서 전화번호 목록을 추출하는 방법으로, 연락처 XML 문서 전체를 메모리로 읽은 후 각 연락처 엘리먼트를 돌면서 각 연락처 내에서 다시 반복해서 전화번호를 추출해도 된다.

DOM은 XML 구조를 보존하고 이해하므로 응용 프로그램에서 구조 전체나 개별 엘리먼트를 쉽게 참조하고 조작할 수 있다. 예를 들어, 연락처 예제에서 SAX를 사용하는 경우는 새 연락처를 추가하기가 쉽지 않다. 하지만 DOM을 사용하는 경우는 새 연락처를 표현하는 새 XML 엘리먼트를 기존 XML 엘리먼트에 추가하면 그만이다.

반면, DOM은 파일을 스트림으로 처리하기 어렵다는 단점이 있다. 예를 들어, SAX에 비해 XML을 HTML로 변환하기가 까다롭다. DOM에서 XML을 HTML로 변환하려면 구조 내 모든 엘리먼트를 돌면서 문서를 처리해야 한다.

또한 DOM은 문서 전체를 메모리로 읽어들이므로 속력이 느려지고 메모리가 많이 필요하다. 반면, 문서 전체를 분석해 메모리에 보존하므로 장점도 존재한다. 예를 들어, XML 문서를 한 번만 분석하면 추가적인 부하 없이 여러 차례 사용할 수 있다. SAX에서 같은 결과를 얻으려면 매번 XML 문서를 다시 분석해야 한다.

DOM과 SAX에 관한 내용과 예제는 참고자료를 살펴본다.

위로

좋은 XML 편집기를 사용하라

XML을 자주 작성하고 사용한다면 좋은 XML 편집기는 필수다. XML 편집기는 일반 텍스트 편집기와 다르다. XML 편집기는 XML 구조와 레이아웃을 이해하며, XML 편집에 유용한 기능을 많이 제공한다. 몇 가지 예를 들자면 다음과 같다.

• 완성 — 닫는 엘리먼트를 입력하기 시작하면 편집기가 자동으로 완성한다.
• 내용 완성 — DTD를 지정하면 편집기가 내용을 자동으로 채우고 형식을 잡아준다. 예를 들어, 연락처 DTD에서 phone 엘리먼트는 type 속성이 필수다. 똑똑한 XML 편집기라면 사용자가 phone 태그를 입력할 때 type 속성을 자동으로 추가한다(속성 값은 비워둔다).
• 인라인 형식 지정 — XML 편집기는 XML 문서 가독성과 이해도를 높여준다. 편집하는 과정에서 형식을 잡아주기도 하고 별도 명령을 제공하기도 한다. 어떤 방식이든, 편집기는 판독하기 쉬운 XML 문서를 생성한다.
• 내장 검증 기능 — 편집기는 사용자가 문서를 작성하는 동안 XML 문서 오류를 잡아주고 수정하기 쉽게 문제 부분을 눈에 띄게 표시한다.
• 내장 변환 기능 — 일부 XML 편집기는 XPath, XQuery, XSLT와 같은 변환 기능 등을 포함하여 편집 환경에서 결과를 보여준다.
• 학습과 조작 — 때로 DTD를 정의하기 전에 XML 문서를 생성하는 경우도 있다. 일부 편집기는 XML 파일을 읽어 구조를 학습한 후 DTD를 생성해주므로 시간과 노력이 상당히 절약된다.

좋은 XML 편집기로는 이클립스, oXygenXML 등을 추천한다. 하지만 이 외에도 좋은 편집기가 많으니 찾아보기 바란다.

위로

요약

좋은 습관을 들이면 XML이 제공하는 장점과 기능을 100% 활용하기가 쉬워진다. 또한 초보적인 검증과 구문분석으로 시간과 노력을 낭비할 필요가 없어진다. 이 기사에서 소개하는 좋은 습관 열 가지를 익혀 XML 문서와 자료를 좀 더 효율적이고 효과적으로 사용하기 바란다.

참고자료

• 자바 XPath API(Elliote Rusty Harold, developerWorks, 2007년 6월): XML 문서에서 정보를 찾고 선택하는 기술인 XPath를 소개한다.
  
  
• DOM 이해하기(Nicholas Chase, developerWorks, 2007년 3월): DOM(Document Object Model)과 DOM 문서 구조를 소개한다. 자바 기술을 사용하여 XML 파일에서 문서를 생성하는 방법, 문서를 변경하는 방법, 출력을 뽑아내는 방법도 설명한다.
  
  
• Understanding SAX(Nicholas Chase, developerWorks, 2003년 7월): SAX(Simple API for XML)라고 알려진 DOM 대체 기술을 소개한다. SAX는 XML 문서를 읽으면서 처리하므로, 문서가 모두 저장될 때까지 기다릴 필요가 없다.
  
  
• Introduction to XML(Doug Tidwell, developerWorks, 2002년 8월): XML 기초를 다지기에 적합한 튜토리얼이다.
  
  
• IBM XML 인증: XML 관련 기술 분야에서 IBM 인증 개발자가 되는 방법을 소개한다.
  
  
• XML 기술 라이브러리: 기사와 팁, 튜토리얼, 표준, IBM 레드 북 등 다양한 기술 자료를 제공한다.
  
  
• developerWorks 기술 행사와 웹 캐스트: 최신 기술 동향을 파악할 수 있다.
  
  
• 기술 온라인 서점: 다양한 기술 서적과 기술 자료를 제공한다.
  
  
• developerWorks 포드캐스트: IBM 기술 전문가들이 나누는 토론과 흥미로운 인터뷰 자료를 제공한다.

• libxml2: xmllint 도구는 Gnome 프로젝트에서 개발한 XML C 구문분석기와 툴킷이다. 리눅스, 유닉스, 맥 OS X은 기본적으로 xmllint 도구를 포함한다. 윈도에서는 별도로 내려 받아야 한다.
  
  
• oXygenXML: XML 문서를 생성하고 검증하고 처리하는 XML 편집기다.
  
  
• 이클립스 IDE: 유명한 개발 플랫폼으로, XML을 처리하는 응용 프로그램을 개발할 때 편리한 XML 편집 기능도 포함한다.
  
  
• 제품 평가를 위한 IBM 평가판 소프트웨어: developerWorks에서 직접 내려 받아 다음 프로젝트에 활용해보자. 들어있는 미들웨어와 응용 프로그램으로는 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®를 포함한다.
  
  

• XML 포럼: XML 관련 주제를 토론하는 포럼에 참여하자.
  
  
• developerWorks XML zone: Share your thoughts: 기사에 관한 의견을 나누는 포럼이다. 중재는 XML 영역 편집자들이 맡는다. 언제든지 의견을 보내주기 바란다.
  
  
• developerWorks 블로그: 블로그를 읽어보고 developerWorks 공동체에 참여하자.
  
  

필자소개

		Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로