 | |
|
난이도 : 초급 Martin Brown, 개발자 겸 필자, 프리랜서
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 10 월 07 일 이 기사에서는 웹 서비스 기초에서 정보 설명에 이르기까지 다양한 문제에 대한 해결책을 제공하는 XML 스키마 중 가장 많이 쓰이는 스키마 열 개를 살펴봅니다. 이 과정에서 연락처(contact)나 송장(invoice) 등 데이터베이스와 비슷한 해결책도 알아봅니다. 이 기사에서 선택한 스키마 열 개는 XML 형식으로 정보를 공유하고 교환한다는 관점에서 유용성, 실용성, XML 공동체에 미치는 영향을 토대로 선별했습니다.
SOAP
|
자주 사용하는 약어
- Ajax: Asynchronous JavaScript + XML
- CPU: Central Processing Unit
- CSS: Cascading Stylesheets
- HTML: Hypertext Markup Language
- OASIS: Organization for the Advancement of Structured Information Standards.
- PDF: Portable Document Format
- W3C: World Wide Web Consortium
- XHTML: Extensible HyperText Markup Language
- XML: Extensible Markup Language
- XSLT: Extensible Stylesheet Language Transformations
|
|
SOAP(Simple Object Access Protocol)은 사실상 웹 서비스 기술이다. 구체적으로는 웹 서비스에서 클라이언트와 서버 사이에서 정보를 교환하는 자료 형식으로, 유연성이 좋은 XML 스키마 중 하나다.
웹 서비스가 제공하는 장점 중 하나는 고도의 상호운용성(interoperability)이다. 웹 서비스를 제공하는 서버와 웹 서비스를 사용하는 클라이언트는 네트워크 상에서 다양한 정보와 자료를 주고 받는다. SOAP 표준은 XML을 사용하여 아키텍처에 중립적인 형식으로 자료 유형과 정보 구조를 정의한다.
흔히 웹 서비스 사용자는 (자신이 선택한 프로그래밍 언어로) 호출하려는 원격 함수 이름과 인수만 제공하면 충분하다. 그러면 SOAP 라이브러리가 함수 이름과 인수 정보를 XML 메시지로 변환한다.
SOAP 구조가 궁금하다면 W3 콘소시엄에서 제공하는 예제를 살펴본다. 원격 SOAP 함수 GetEndorsingBoarder()를 호출하면 SOAP 라이브러리는 Listing 1과 같은 XML 메시지를 생성한다.
Listing 1. 원격 SOAP 함수 GetEndorsingBoarder() 호출
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
<manufacturer>K2</manufacturer>
<model>Fatbob</model>
</m:GetEndorsingBoarder>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
SOAP 클라이언트가 보내는 전체 메시지는 SOAP 인벨롭(Envelope)이라는 형식으로 인코딩된다. 실제 메시지 내용은 SOAP 인벨롭 내용으로 들어간다.
Listing 1을 보면, SOAP 클라이언트가 호출하는 원격 함수는 GetEndorsingBoarder이며, 함수가 받는 인수는 manufacturer와 model이라는 사실이 명백히 드러난다. 즉, 원래 프로그래밍 언어에서는 십중팔구 이진 형식이었을 정보가 XML 형식으로 분명히 표현된다. XML은 플랫폼에 독립적이므로 각 호스트는 (복잡한 이진 정보를 인코딩하거나 디코딩할 필요 없이) SOAP 시스템을 사용하여 XML 메시지를 쉽게 주고 받을 수 있다.
서버가 보내는 응답 역시 XML 형식의 SOAP 인벨롭이다. 이번에는 함수 반환값이 SOAP 인벨롭 내용으로 들어간다. SOAP 응답은 상응하는 SOAP 요청과 항상 똑같은 형식이다. 단, 상세 정보에 Response가 덧붙는다. 자세한 내용은 Listing 2를 참조한다.
Listing 2. SOAP 요청을 보낸 후 받은 응답
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
<endorsingBoarder>Chris Englesmann</endorsingBoarder>
</m:GetEndorsingBoarderResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
일반적으로는 사용자가 SOAP 메시지를 직접 작성하지 않는다. SOAP 라이브러리가 알아서 만들어 준다. 하지만 SOAP 인벨롭 구조 자체는 아주 간단하므로 SOAP 표준을 사용하여 정보를 공유하기는 어렵지 않다.
SOAP 표준을 사용하면 원격 함수를 호출하고 원격 함수와 정보를 교환하기가 매우 쉬워진다. RPC(Remote Procedure Call) 표준을 사용하려면 이진 자료를 직렬화하는 복잡한 메서드가 필요하며, 좀 더 구조화된 정보를 전송하므로 원본 자료를 상세히 선언하고 변환해야 한다.
SOAP을 사용하면, XML로 직렬화하는 과정이 간단해지고, 플랫폼과 언어에 독립적이며, 자료 교환이 훨씬 쉬워진다.
WSDL
WSDL(Web Services Description Language)은 웹 서비스를 기술하는 편리한 방법이다(대부분 SOAP을 사용한다). WSDL을 사용하면 SOAP 표준을 사용하는 서비스와 인터페이스를 기술할 수 있다.
예를 들어, 개별 서버가 제공하는 웹 서비스를 WSDL 파일로 기술한 후 웹 서비스를 사용하려는 소비자에게 이 파일을 배포한다. 그러면 소비자는 WSDL 파일을 읽어서 해석하는 방식으로 웹 서비스 사용법을 파악하게 된다. WSDL 파일은 웹 서비스와 주고 받을 자료 유형과 인수, 웹 서비스가 반환하는 오류나 기타 정보 등을 포함한다.
W3가 제공하는 예제를 다시 살펴보자. Listing 3에서 보듯이, 서버와 클라이언트가 주고 받을 자료와 클라이언트가 호출할 원격 함수가 XML 형식으로 정의되어 있다.
Listing 3. 다양한 원격 함수와 교환 대상 자료가 정의된 XML 파일
<?xml version="1.0"?>
<!-- root element wsdl:definitions defines set of related services -->
<wsdl:definitions name="EndorsementSearch"
targetNamespace="http://namespaces.snowboard-info.com"
xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<!-- wsdl:types encapsulates schema definitions of communication types;
here using xsd -->
<wsdl:types>
<!-- all type declarations are in a chunk of xsd -->
<xsd:schema targetNamespace="http://namespaces.snowboard-info.com"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<!-- xsd definition: GetEndorsingBoarder [manufacturer string,
model string] -->
<xsd:element name="GetEndorsingBoarder">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="manufacturer" type="string"/>
<xsd:element name="model" type="string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- xsd definition: GetEndorsingBoarderResponse
[... endorsingBoarder string ...] -->
<xsd:element name="GetEndorsingBoarderResponse">
<xsd:complexType>
<xsd:all>
<xsd:element name="endorsingBoarder" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
<!-- xsd definition: GetEndorsingBoarderFault
[... errorMessage string ...] -->
<xsd:element name="GetEndorsingBoarderFault">
<xsd:complexType>
<xsd:all>
<xsd:element name="errorMessage" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<!-- wsdl:message elements describe potential transactions -->
<!-- request GetEndorsingBoarderRequest is of type GetEndorsingBoarder -->
<wsdl:message name="GetEndorsingBoarderRequest">
<wsdl:part name="body" element="esxsd:GetEndorsingBoarder"/>
</wsdl:message>
<!-- response GetEndorsingBoarderResponse is of type
GetEndorsingBoarderResponse -->
<wsdl:message name="GetEndorsingBoarderResponse">
<wsdl:part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
</wsdl:message>
<!-- wsdl:portType describes messages in an operation -->
<wsdl:portType name="GetEndorsingBoarderPortType">
<!-- the value of wsdl:operation eludes me -->
<wsdl:operation name="GetEndorsingBoarder">
<wsdl:input message="es:GetEndorsingBoarderRequest"/>
<wsdl:output message="es:GetEndorsingBoarderResponse"/>
<wsdl:fault message="es:GetEndorsingBoarderFault"/>
</wsdl:operation>
</wsdl:portType>
<!-- wsdl:binding states a serialization protocol for this service -->
<wsdl:binding name="EndorsementSearchSoapBinding"
type="es:GetEndorsingBoarderPortType">
<!-- leverage off soap:binding document style ...(no wsdl:foo pointing at
the soap binding) -->
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- semi-opaque container of network transport details classed by
soap:binding above ... -->
<wsdl:operation name="GetEndorsingBoarder">
<!-- again bind to SOAP? ... -->
<soap:operation soapAction="http://www.snowboard-info.com/
EndorsementSearch"/>
<!-- further specify that the messages in the wsdl:operation
"GetEndorsingBoarder" use SOAP? ... -->
<wsdl:input>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:output>
<wsdl:fault>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<!-- wsdl:service names a new service "EndorsementSearchService" -->
<wsdl:service name="EndorsementSearchService">
<wsdl:documentation>snowboarding-info.com Endorsement Service</
wsdl:documentation>
<!-- connect it to the binding "EndorsementSearchSoapBinding" above -->
<wsdl:port name="GetEndorsingBoarderPort"
binding="es:EndorsementSearchSoapBinding">
<!-- give the binding an network address -->
<soap:address location="http://www.snowboard-info.com/EndorsementSearch"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
WSDL은 메시지 유형, 폴트 유형과 내용, 교환할 자료 구조를 선언한다.
WSDL은 클라이언트가 SOAP 인터페이스로 웹 서비스를 사용할 때 필요한 모든 정보를 제공한다. 대다수 언어와 환경은 WSDL을 읽고 해석하여 함수와 자료를 추출하는 메커니즘을 제공한다.
WSDL은 정보 교환 시 클라이언트가 사용할 SOAP 인터페이스를 정의할 뿐만 아니라, 적당한 WSDL 생성기(generator)가 있다면, 요청을 전송하고 응답을 인식하는 코드를 생성할 때도 사용할 수 있다.
WSDL과 SOAP을 함께 사용하면 강력한 원격 프로시저 호출 시스템을 만든다.
RDF
시맨틱 웹(Semantic Web)과 시맨틱 그리드(Semantic Grid)는 둘 다 RDF(Resource Description Framework)가 제공하는 기술 언어(description language)를 사용한다. 사실 RDF 형식은 여러 표준을 묶어놓은 집합이다. RDF를 사용하면 여러 곳에 흩어진 정보와 자원을 연결하고 연관짓는 방법으로 정보와 자료를 묘사한다.
RDF는 W3가 인정하는 표준이며 정보와 자원을 정의한다. XML만이 RDF를 표현하는 유일한 방법은 아니다. 하지만 직렬화 형식 중 하나가 XML로 정보를 기술한다.
자원은 주어-술어-목적어(Subject-Predicate-Object) 형식으로 정의한다. 예를 들어, 웹 사이트 내용을 정의할 때 주어는 ‘웹 사이트(web site)’, 술어는 ‘포함한다(contains)’, 목적어는 내용 유형(content type)이 된다. 웹 사이트와 다른 자원 간에 관계를 생성하려면 FOAF(Friend of a Friend) 표기법을 사용하여 두 자원 사이에 링크를 생성한다.
RDF를 사용하는 목적은 정보와 자원을 기술하는 자연 언어를 컴퓨터가 이해하는 형식으로 표현하기 위해서다. 예를 들어, The MCSLP.com Website is authored by Martin C Brown이라는 문장을 RDF XML 형식으로 기술하면 Listing 4와 같다.
Listing 4. RDF XML로 다시 표현한 문장
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:si="http://www.recshop.fake/siteinfo#">
<rdf:Description rdf:about="http://www.mcslp.com/ ">
<si:author>Martin C Brown</si:author>
</rdf:Description>
</rdf:RDF>
|
RDF를 사용하는 또 다른 예제는 초창기 신디케이션 시스템이다. 초창기 뉴스 사이트와 블로그는 RDF 명세를 사용하여 피드 내용과 개별 포스팅을 정의했다. 예제는 Listing 5를 참조한다.
Listing 5. RDF 명세로 정의한 피드 내용과 개별 포스팅
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/">
<channel>
<title>MCslp</title>
<link>http://www.mcslp.com</link>
<description>MCslp Projects</description>
</channel>
<item>
<title>Voice enabling XMLtitle>
<link>http://mcslp.com/?p=295link>
</item>
...
</rdf:RDF>
|
원래 RDF 표준은 웹 상에서 자원, 내용, 관계를 기술하려는 구체적인 목적으로 설계되었다. 그러나 지금은 일반적인 정보, 자원, 관계를 기술하는 표준으로 사용된다.
시맨틱 웹과 시맨틱 그리드에서 응용 프로그램이 다양한 정보를 활용하고 자료를 서로 연관지으려면 자원과 관계를 정의하는 표준이 필수적이다.
vCard
모든 비즈니스 응용 프로그램에서 연락처 정보 관리는 필수다. 이 때 정보 획득에 효과적인 XML 구조를 사용하면 정보를 관리하기가 훨씬 수월해진다.
연락처 정보는 가변성이 많아서 XML이 가장 적합한 방법으로 꼽힌다. 예를 들어, 어떤 회사나 개인은 주소, 전화번호, 전자편지 주소가 여러 개다. XML 구조를 사용하면 무리 없이 이런 다중 정보 조각을 관리할 수 있다.
vCard는 인터넷에서 자주 사용되며, 플랫폼에 독립적인 방식으로 연락처 정보를 표현하므로, 다양한 응용 프로그램에서 연락처 정보를 생성하거나 교환하기 편리하다. vCard는 XML 구조의 유연성을 어느 정도 지원하지만, 사실은 필드와 확장자가 정해진 간단한 텍스트 파일이다. XML과는 달리 vCard 형식은 1차원 파일이다. 즉, 다른 엘리먼트에 정보를 곧바로 첨부하지 못한다는 뜻이다. 전화번호가 좋은 예로, 전화번호는 명시적인 주소에 연결하지 못한다. 단지 또 다른 전화번호로만 추가할 수 있다.
W3C는 RDF XML에 기반을 둔 vCard XML 형식을 제안한다. 이 형식을 사용하면 연락처 정보를 생성하고 교환하기가 더욱 쉬워진다. RDF를 프레임워크로 사용하면 선언 과정에서 구조 정보 일부를 보존할 수 있다. 예를 들어, RDF 표준은 자료 기술 방법으로 백(bag), 순서(sequence), 대체물(alternative)을 지원한다. 백(bag)은 개체를 여러 번 선언할 때 사용하며 순서는 없다. 역할이 여러 개인 경우처럼 순서가 중요하지 않을 때 사용한다. 순서(sequence)는 개체 순서를 정의할 때 사용한다. 예를 들어, 조직 내에서 역할 계층을 정의할 때 사용하면 적합하다. 대체물(alternative)을 사용하면 목록에서 한 항목을 선택할 수 있다. 예를 들어, 여러 전자편지 주소에서 하나를 선택할 수 있다.
Listing 6은 Charles Perston이라는 가상 인물을 위한 전형적인 vCard다.
Listing 6. Charles Perston이라는 가상 인물을 위한 전형적인 vCard
BEGIN:VCARD
VERSION:3.0
N:Perston;Charles;;;
FN:Charles Perston
ORG:Perston Technology;
EMAIL;type=INTERNET;type=WORK;type=pref:null@perston.co.uk
TEL;type=WORK;type=pref:01234 567890
item1.ADR;type=WORK;type=pref:;;Perston House;Perston;Perstonshire;P1 0NS;UK
item1.X-ABADR:gb
X-ABUID:5AE47BB6-4E0F-4558-980C-BD3066FA6154\:ABPerson
END:VCARD
|
Listing 7은 vCard XML 표준을 사용하여 Listing 6을 표현한 결과다.
Listing 7. vCard XML 표준을 사용하여 Charles Perston이라는 가상 인물을 표현한 결과
<vCard:vCard xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:foaf="http://xmlns.com/foaf/0.1/" vCard:version="3.0"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" vCard:class="PUBLIC"
xmlns:vCard="x-urn:cpan:ascope:xml-generator-vcard#">
<vCard:fn>Charles Perston</vCard:fn>
<vCard:n>
<vCard:family>Perston</vCard:family>
<vCard:given>Charles</vCard:given>
</vCard:n>
<vCard:adr vCard:del.type="pref;work">
<vCard:street>Perston House</vCard:street>
<vCard:locality>Perston</vCard:locality>
<vCard:region>Perstonshire</vCard:region>
<vCard:pcode>P1 0NS</vCard:pcode>
<vCard:country>UK</vCard:country>
</vCard:adr>
<vCard:email vCard:email.type="internet;pref;work">null@perston.co.uk
</vCard:email>
<vCard:org>
<vCard:orgnam>Perston Technology</vCard:orgnam>
</vCard:org>
</vCard:vCard>
|
Listing 7이 Listing 6보다 길이는 길지만 가독성은 더 높다. 각 구성요소가 서로 연관되는 모습을 파악하고, 필요한 구체적인 정보를 찾아내기가 쉽다. 예를 들어, 상대적으로 꼭꼭 숨겨진 표준 vCard 출력을 담은 Listing 6보다 Listing 7에서 국가 정보를 찾아내기가 훨씬 쉽다.
또한 XPath나 SAX 이벤트를 사용하여 (연락처 분포를 파악할 목적으로) 국가 목록을 출력하는 등 정보를 검색하고 조작하기도 쉽다.
DocBook XML
문서를 한 번만 작성한 후 필요한 형식으로 다양하게 출력하는 기능은 많은 조직에서 오랫동안 바라던 것이다. DocBook XML이 바로 이런 목적에 쓰인다. DocBook XML을 사용하면 의미적 마크업(semantic markup)을 보존하면서 동시에 결과물에 대한 출력 형식도 제어할 수 있다.
의미적 마크업은 문서를 구성하는 장(chapter), 절(section), 단락(paragraph)을 지정한다. 단락에 들어가는 항목도 구체적으로 지정할 수 있다. 예를 들어, Listing 8에서 보듯이, 명령 이름과 함수 이름을 각자 정해진 태그로 감쌀 수 있다.
Listing 8. 명령과 함수를 각자 정해진 태그로 감싸기
<para>The <command>compile</command> takes the source code of the
material and builds a new class based on the filename. For example, if the filename is
<filename>HelloWorld</filename> then the name of the class generated will be
<classname>HelloWorld</classname>.
|
문서를 출력할 때는 요소마다 다른 스타일과 형식을 지정해도 좋고 모든 요소에 같은 스타일과 형식을 지정해도 좋다. 좀 더 중요하게는, 의미적 정보를 다양한 방법으로 활용할 수 있다. 예를 들어, 문서에서 여러 클래스 이름을 사용한다면, 나중에 문서에서 사용하는 전체 클래스 이름 목록을 추출할 수 있다.
이러한 의미적 마크업 외에도 각 절이나 문단에 구체적인 ID를 부여한 후 문서 내 다른 곳에서 이런 ID를 사용해 링크를 생성해도 된다. 장이나 절 등 최종적으로 목차에 들어가는 구성요소는 자동으로 ID가 부여되고 링크가 생성된다. 이 외에는 작성자가 직접 ID를 부여한 후 링크를 생성하면 된다.
문서를 특정한 형식으로 변환하면, 링크는 자동으로 적절한 형식으로 변환된다. 예를 들어, 문서를 HTML로 변환하면, 링크는 다른 페이지나 페이지 내 특정 위치를 가리키는 HTML 링크가 된다. PDF를 생성할 때는 대상 절의 페이지 번호를 포함시킬 수 있다.
이런 변환은 XSLT 스타일시트가 처리한다. 표준 DocBook XSLT 스타일시트는 XML 문서를 표준 HTML, XHTML, PDF(FO 표준을 통해), Texinfo, 자바(Java™) 도움말, 매뉴얼 페이지 중 하나로 변환한다. 표준 스타일시트를 사용하면 출력 결과물에 대한 크기나 스타일을 책 형식에서 A4, 슬라이드까지 다양하게 지원한다.
이렇듯 다양한 출력 형식과 마크업을 지원하므로 문서 하나만 작성한 후 종이 매뉴얼, 소프트웨어 도움말, 매뉴얼 페이지, 문맥 감지 온라인 도움말 등 다양한 형식으로 변환할 수 있다. 전통적인 방식에서라면 모든 문서를 별도로 작성해야 할 것이다.
DocBook XML은 기술 문서 작성에 광범위하게 쓰인다. 현재 많은 회사가 DocBook XML 표준을 (혹은 DocBook에서 파생한 표준을) 이용하여 문서를 작성한다.
FIXML
FIXML은 B2B(Business-to-Business) 정보 교환 형식 중 하나로, 금융 기관이 정보를 교환할 때 사용한다. 구체적으로, 계좌 이체 정보에서 간단한 주식 가격과 무역 정보에 이르기까지 다양하고도 중요한 정보를 다룬다.
이런 금융 정보는 상대적으로 작은 패킷에서 종종 훨씬 큰 자료 블록에 이르기까지 다양한 크기로 전송된다. 예전에는 전통적인 형식인 간단한 키/값 쌍으로 이런 정보를 전송했으나, 이와 같은 방식에서는 교환하는 정보 크기가 효율적이지 못했다. 하지만 XML을 도입하면서 특히 복잡한 정보를 간단한 구조로 표현할 수 있게 되었다.
FIXML 표준 중에서도 최적화된 버전을 정보 교환 형식으로 채택한 이후로 자료 파일 크기는 크게 줄어들었고 파일 가독성은 크게 높아졌다. 주가 정보를 교환하는 파일 크기는 예전 형식보다 거의 1/4로 감소했다.
금융 기관을 제외하면 FIXML은 거의 쓰이지 않는다. 하지만 FIXML이 금융 정보를 효율적으로 전송함으로써 궁극적으로는 모두에게 이익이 돌아온다.
SVG
SVG(Scalable Vector Graphics)는 일러스트레이션을 기술하는 XML 표준이다. SVG를 사용하면 선, 형상, 형상의 위치와 관계를 기술할 수 있다. 가장 큰 장점은 이러한 정보를 (크기 조정이 가능한 도표, 고정된 그래픽 등) 원하는 형식으로 출력할 수 있다는 점이다.
SVG는 일러스트레이션을 생성하던 전통적인 방식을 크게 개선한다. 기존 방식은 몇 가지 심각한 문제가 있었다. 우선, 예전에는 특수한 일러스트레이션 프로그램을 사용했다. 따라서 다양한 프로그램이 일러스트레이션을 공유하기란 매우 어려웠다. 하지만 이제 파일을 SVG 형식으로 저장하면 SVG를 인식하는 프로그램 어디서나 파일을 인식해 작업할 수 있다.
또한 일러스터레이션을 문서에 (특히 웹 페이지에) 넣으려면 (JPEG, PNG 등과 같은) 비트맵 형식으로 변환해야 한다. 이런 전통적인 방식에는 몇 가지 문제가 있다. 첫째, 원래 일러스트레이션을 명시적으로 (흔히 수동으로) 비트맵 형식으로 변환해야 한다.
둘째, 비트맵 형식은 원본 그림을 픽셀로 표현하므로 출력 목표에 맞춰 이미지 크기와 해상도를 주의깊게 정해야 최종 이미지 품질이 떨어지지 않는다. 예를 들어, 일반 모니터용이라면 화면 해상도를 대다수 모니터 표준에 맞춰 72dpi 또는 96dpi로 잡아야 한다. 인쇄용으로는 300dpi에서 2400dpi 정도가 필요하다. 즉, 원본 일러스트레이션 크기에 비해 이미지 파일 크기가 상대적으로 매우 커진다.
PostScript와 Encapsulated PostScript가 나오기 전에도 벡터 그래픽 형식이 존재했지만, CPU를 많이 사용하는 탓에 화면 표현용으로는 부적합했다.
SVG는 여느 벡터 그래픽 형식처럼 픽셀 단위 표현이 아니라 형상 목록으로 이미지를 기술한다. 예를 들어, 직사각형은 상단 왼쪽 꼭지점을 지정한 후 높이와 너비를 지정한다. 이미지를 기술하는 파일 형식은 XML이다. 선, 직사각형, 다각형, 원 등을 기술하는 태그가 별도로 존재하여, 각 요소의 모양새와 다양한 구성 요소의 형식을 전적으로 제어할 수 있다.
Listing 9는 간단한 사각형, 투명한 원, 투명한 삼각형을 그리는 예제다.
Listing 9. 간단한 사각형, 투명한 원, 투명한 삼각형 그리기
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">
<polygon
points="200,100 300,200 150,250"
style="fill:#cccccc;
stroke:#000000;stroke-width:1"/>
<rect x="20" y="20" width="250" height="250"
style="fill:blue;stroke:black;stroke-width:1;
fill-opacity:0.1;stroke-opacity:0.9"/>
<circle cx="100" cy="50" r="40" stroke="red"
fill="red" style="fill-opacity:0.5"/>
</svg>
|
그림 1은 Listing 9를 비트맵으로 표현한 이미지다.
그림 1. 비트맵으로 그린 버전
SVG 파일(Listing 1)은 이미지 묘사에 크기가 500바이트를 넘지 않지만, PNG 파일(그림 1)은 거의 9KB에 달한다.
SVG를 사용하면 일러스트레이션 크기가 작아지고, 사용이 편해지며, 광범위한 응용 프로그램과 호환이 가능해진다.
더블린 코어(Dublin Core)
더블린 코어는 대부분 도서관에서 많이 사용하는 정보를 분류하는 방법으로, 더블린 코어 표준과 연동하여 이러한 정보를 XML로 정의하는 XML 스키마가 존재한다. 더블린 코어 표준은 온갖 정보를 카탈로그로 만들어 효과적으로 조회하고 갱신하고 사용하려는 경우에 유용하다.
현재 정보 정의와 설명 분야에서 더블린 코어는 시맨틱 웹(Semantic Web)을 현실화하는 데 기여하고 있다. 정보를 기술하는 표준을 제공함으로써, 더욱 중요하게는 체계적으로 검증된 해결책을 제시함으로써, XML 문서로 정보를 상세히 기술하며 다양한 자원 사이에 정보를 효과적으로 교환하고 비교할 수 있다.
더블린 코어 명세는 자체 스키마가 존재한다. 하지만 더블린 코어 스키마는 다른 XML 문서에 포함될 목적으로 설계되었다. 더블린 코어 스키마를 다른 문서에서 사용할 때는 XML 이름 공간을 지정하여 DC 엘리먼트를 정의한다. 예를 들어, Listing 10은 RDF XML 스키마 내에서 RDF 엔티티 내용을 기술하는 DC 분류 시스템이다. Listing 10에서는 RDF 엔티티로 웹 사이트를 기술한다. 아래 예제는 앞서 RDF 스키마에서 보았던 예제를 확장한다.
Listing 10. RDF XML 스키마 내에서 RDF 엔티티 내용을 기술하는 DC 분류 시스템
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rss:channel rdf:about="http://www.xml.com/xml/news.rss">
<rss:title>MCSLP</rss:title>
<rss:link>http://mcslp.com/rss </rss:link>
<dc:description>
MCSLP features information, projects and articles from members of the MCSLP team.
</dc:description>
<dc:subject>MCSLP, Grids, XML, Databases, Programming </dc:subject>
<dc:identifier>http://www.mcslp.com</dc:identifier>
<dc:publisher>MCSLP</dc:publisher>
<dc:rights>Copyright 2008, MCSLP</dc:rights>
</rdf:RDF>
|
Listing 10에서 DC 엘리먼트를 사용하여 설명(Description), 주제(Subject), 발행처(Publisher), 이용조건(Rights), 식별자(identifier) 정보를 추가했다. 이런 정보를 이용하면 RSS 피드 내용을 분류하기가 쉬워진다.
더블린 코어 메타데이터 엘리먼트 집합은 메타데이터 엘리먼트 15개로 이뤄진다(옮긴이 주: 메타데이터 엘리먼트 한글 용어는 한국 더블린 코어 메타데이터를 참조했다).
- 제목(Title)
- 제작자(Creator)
- 주제(Subject)
- 설명(Description)
- 발행처(Publisher)
- 기타 제작자(Contributor)
- 날짜(Date)
- 자료 유형(Type)
- 형식(Format)
- 식별자(Identifier)
- 출처(Source)
- 언어(Language)
- 관련자료(Relation)
- 내용범위(Coverage)
- 이용조건(Rights)
이상 15개 엘리먼트를 사용하면 매우 다양한 정보를 기술할 수 있다.
XForms
XForms XML 표준을 사용하면 (필드, 라디오 버튼, 리스트 같은 입력 유형 등) 다양한 폼 구성요소를 정의할 수 있다. 또한 사용자가 폼에 입력한 정보를 검증할 수도 있다.
XForms XML 표준은 많은 개발자에게 이미 익숙한 HTML 폼이나 XHTML 폼과 매우 비슷하며, XHTML 2.0 표준에서는 XForms를 지원할 예정이다.
XForms XML은 간단한 MVC(Model, View, Controller) 형식에 기반을 둔다. 여기서 모델(Model)은 폼을 전반적으로 기술하며 여기에는 필드, 입력 조건, 자료 제출 모드 등이 포함된다. 뷰(View)는 폼에 표시되는 컨트롤, 컨트롤 그룹, 컨트롤이 제어하는 필드를 정의한다. 폼에서 개별 컨트롤 형식과 외양은 CSS에서 제어한다.
XForms 표준은 기존 HTML 폼 정의를 확장하여 폼에 입력되는 정보를 좀 더 상세하게 분류한다. 폼을 채우는 과정에서 (보통 자바스크립트나 Ajax를 사용할 때만 지원되는) 동적 요소를 사용할 수도 있다.
Listing 11에서 간단한 텍스트 입력 창과 팝업 선택 상자 예를 볼 수 있다.
Listing 11. 간단한 텍스트 입력 창과 팝업 선택 상자
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xforms="http://www.w3.org/2002/xforms">
<head>
<title>XForms Sample</title>
<xforms:model>
<xforms:instance>
<Name xmlns="">
<FName />
<LName />
<Title />
</Name>
</xforms:instance>
</xforms:model>
</head>
<body>
<xforms:select1 ref="Title">
<xforms:label>Title:</xforms:label>
<xforms:item>
<xforms:label>Mr</xforms:label>
<xforms:value>Mr</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Mrs</xforms:label>
<xforms:value>Mrs</xforms:value>
</xforms:item>
</xforms:select1>
<xforms:input ref="FName">
<xforms:label>First name: </xforms:label>
</xforms:input>
<xforms:input ref="LName">
<xforms:label>Last name: </xforms:label>
</xforms:input>
<hr />
<xforms:output value="concat('Hello ',Title,' ',FName,' ',LName)">
<xforms:label>Output: </xforms:label>
</xforms:output>
</body>
</html>
|
파이어폭스 XForms 확장 기능을 사용하면 HTML에서 XForms 폼을 볼 수 있다. 예제는 그림 2를 참고한다.
그림 2. 파이어폭스 XForms 확장 기능을 사용하여 HTML에서 XForms 폼 보기
고객 송장(Customer Invoice)
많은 비즈니스 프로세스에서 고질적인 문제 중 하나가 기존에 종이로 관리하던 고객 송장을 컴퓨터로 옮기는 작업이다. 송장 구조를 생성할 때는 다양한 유형과 반복적인 요소를 주의 깊게 고려해야 사용하기 쉬운 구조가 나온다.
과거에는 아주 큰 구조를 정의하여 송장과 같은 비즈니스 정보를 교환했다. 송장 정보를 교환하는 국제 표준은 수백 가지에 달하는 필드를 정의한다. 따라서 정보를 교환하는 좀 더 효과적인 방법이 없다면 송장, 주문 같은 비즈니스 정보를 공유하기가 어려워진다.
전세계적으로 통일된 표준이 없는 탓에 많은 조직이 나름대로 핵심 송장 표준을 개발해 내놓았다. 이 중에서 가장 널리 알려진 표준은 OASIS 그룹이 개발한 표준으로, 많은 회사와 조직이 이 표준을 채택했다.
OASIS가 개발한 프레임워크 중 일부가 UBL(Universal Business Logic)이라는 구조다. 이 구조는 주문 처리에서 송장과 결제에 이르기까지 모든 스키마와 워크플로를 제공한다. 시스템 자체는 너무 복잡하여 이 기사 범위를 벗어나므로 여기서는 자세히 설명하지 않는다. 하지만 확장성과 상호운용성이 있는 시스템을 찾는다면 UBL을 살펴보라고 권한다.
요약
이 기사에서는 간단한 기술 프레임워크인 RDF, 그래픽 형식인 SVG, 비즈니스 워크플로를 지원하는 구조인 UBL에 이르기까지 다양한 XML 스키마를 살펴보았다. 각 XML 스키마를 소개하면서 XML 표준을 사용하면 구조와 내용의 유연성 때문에 해당 분야의 시스템 개발이 쉬워진다는 사실을 확인했다. 또한 XML이 제공하는 교차 플랫폼 호환성은 다양한 플랫폼과 환경에서 정보를 교환하기에 적합하다는 사실도 확인했다. 특히 WSDL과 SOAP에서는 이 교차 플랫폼 호환성이 가장 중요한 장점으로 꼽힌다.
참고자료 교육
- XML.org: SOAP, WSDL, SVG 등 다양한 XML 스키마를 소개한다.
- The OASIS Universal Business Logic(UBL): XML을 사용하여 주문 전과정을 처리하는 시스템과 워크플로를 제공한다.
- The XForms standard: W3 콘소시엄이 제정한 XML 표준 중 하나를 설명한다.
- The Dublin Core Metadata Initiative(DCMI): 더블린 코어 시스템을 개발하고 명세하는 조직이다. 더블린 코어는 XML 문서로 메타 정보를 표현하는 표준 형식 중 하나다.
- Scalable Vector Graphics(SVG): 벡터 형식을 기술하는 표준을 설명한다.
- vCard XML: XML을 사용하여 연락처 정보를 여러 응용 프로그램에서 교환이 가능하도록 표현하는 방법을 소개한다.
- Introduction to XML(Doug Tidwell, developerWorks, 2002년 8월): XML 기초를 소개하는 튜토리얼이다.
- SOAP 애플리케이션에서 WSDL 사용하기(Uche Ogbuji, 한국 developerWorks, 2000년 11월): SOAP 프로그래머를 대상으로 WSDL을 소개한다.
- Introduction to Scalable Vector Graphics(Nicholas Chase, developerWorks, 2004년 3월): SVG 문서 작성에 필요한 개념을 소개한다. 기본 형상, 경로, 텍스트, 모델 색깔 입히기, 애니메이션, 스크립팅 등을 다룬다.
- Understanding XForms(Kurt Cagle, developerWorks, 2007년 6월): XForms의 배경을 상세히 소개한다.
- An introduction to RDF(Uche Ogbuji, developerWorks, 2000년 121월): RDF가 나온 기원을 소개하고 스키마에서 사용 시나리오에 이르기까지 RDF를 활용할 가능성을 짚어본다.
- SVG and XForms: A primer(Antoine Quint, developerWorks, 2003년 11월): SVG와 XForms의 시너지 효과를 살펴보는 기사다.
- IBM XML 인증: XML과 관련 기술 분야에서 IBM 인증 개발자가 되는 방법을 소개한다.
- XML 기술 라이브러리: developerWorks XML 영역에서는 기사와 팁, 튜토리얼, 표준, IBM 레드 북 등 다양한 기술 자료를 제공한다.
- developerWorks 기술 행사와 웹 캐스트: 최신 기술 동향을 파악할 수 있다.
- 온라인 기술 서점: 다양한 기술 서적과 기술 자료를 제공한다.
- developerWorks 포드캐스트: IBM 기술 전문가들이 나누는 토론과 흥미로운 인터뷰 자료를 제공한다.
제품 및 기술 얻기
- IBM 평가판 소프트웨어: developerWorks에서 직접 내려 받아 다음 프로젝트에 활용해보자. DB2®, Lotus®, Rational®, Tivoli®, WebSphere® 같은 응용 개발 도구와 미들웨어 제품을 포함한다.
토론
필자소개 | 
| | 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이 운영하는 웹 사이트를 참조하기 바란다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
