![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
UBL(Universal Business Language)은 구입 주문서 및 송장과 같은 표준 전자 XML 비즈니스 문서로 구성된 로얄티 없는 라이브러리를 정의한다. UBL은 기존의 비즈니스, 법률, 감사 및 기록 관리 관행에 직접 연결되도록 설계되었다. UBL을 이용하면 기존의 팩스와 문서 기반의 공급망에서 키 변경 데이터를 제거할 수 있으며 중소규모 비즈니스를 위한 전자상거래의 시작점을 확보할 수 있다.
모든 UBL 비즈니스 문서는 W3C XSD(XML Schema Definition Language)와 하나의 컴포넌트 콜렉션을 사용하여 공식적으로 정의한다. 각 스키마는 송장이나 구입 주문서와 같은 문서의 클래스를 정의한다. UBL은 XML이기 때문에 일반적인 XML 규칙이 모든 UBL 문서에 적용된다. UBL에 관한 소개 정보는 참고자료에 있는 필자의 또 다른 기사를 읽어보기 바란다.
회사에서 XML 비즈니스 문서를 교환하는 경우에는 유효한 문서를 처리하고 있는지 아는 것도 중요하지만 국가 코드, 통화 코드, 지불 수단이나 부품 번호와 같은 특정 정보 항목의 값도 확인해야 한다. 유효한 국가 코드와 통화 코드의 목록은 국제적으로 관리되는 코드 목록에 해당되지만 구입 주문서에서 고객이 사용하는, 공급자의 유효한 부품 번호 목록은 로컬에서 관리해야 한다. 일반적으로 거래 당사자는 가격 및 로컬 비즈니스 규칙과 관련된 제한조건을 쉽게 그리고 간단하지만 선언적인 방법으로 지정할 수 있어야 한다.
XML로 된 모든 UBL 비즈니스 문서는 최소한 잘 구성되어야 한다. 이는 모든 요소가 적절히 중첩되어야 함을 의미한다. 예를 들어,
<cbc:Party><cbc:PartyName> ... </cbc:PartyName></cbc:Party>는 적절히 중첩되었지만, <cbc:Party><cbc:PartyName> ... </cbc:Party> </cbc:PartyName>은
그렇지 않다. 해당 스키마를 대상으로 인스턴스를 검사하여 인스턴스의 구조와 어휘를 검사할 수도 있다. 예를 들어, UBL 송장이 문서 클래스 invoice의 인스턴스로
확인되면 이 송장은 유효하다고 할 수 있다.
UBL은 애플리케이션에서 다양한 요소의 값을 확인하고 거래 당사자의 특정 요구를 확인하는 과정을 사용자 정의하는 수단을 제공한다. UBL을 소개하는 기사를 읽으려면 참고자료를 확인한다.
때로는 코드 목록을 제어 어휘라고 한다. 요소 값은 고유한 표준 사전정의 값으로 구성된 유한 목록에 있는 값이어야 한다. 이러한 값을 유지보수하는 데 필요한 권한은 누구에게 있을까?
국가 코드와 같은 값은 글로벌하게 적용되고 관리되는 반면에 공급자 제품 코드와 같은 값은 로컬에서만 적용되고 거래 당사자 간이나 이익공동체 내에서 관리된다. 이익공동체 외부에서는 이러한 로컬 목록 유형이 그다지 관련이 없다.
예를 들면, 상품 공급자는 표준 제품코드 목록을 유지보수할 수 있는 반면에 고객은 해당 제품코드를 제공하여 이러한 제품 중 하나를 주문할 수 있다. 이러한 코드가 이익공동체 전체에서 고유하다는 것을 보장할 수는 없으며, 따라서 완전히 다른 제품에 동일한 제품코드를 사용할 수도 있다.
국제표준기구에서 이미 관리하고 있는 글로벌 코드 목록이 있다. 이 목록에는 국제표준화기구(ISO)에서 관리하는 통화 코드(ISO 4217), 국가 코드(ISO 3166-1) 그리고 유엔유럽경제위원회(UNECE)에서 관리하는 지불 수단 코드(UNECE 4461)가 포함되어 있다. UBL은 이러한 코드를 재창조하기 보다는 이러한 코드가 있는 코드 목록을 사용한다.
이익공동체에서 코드 목록의 서브세트만 필요할 수도 있으며 또는 현재 표준 목록에 없는 추가 코드를 제공해야 할 수도 있다. UBL은 로컬에서 사용할 목적으로 표준 코드 목록을 서브세트로 나누고 확장하는 수단을 제공한다.
기존의 프로그래밍에서는 구조, 어휘 및 값의 제한조건을 검사하는 작업은 개별 애플리케이션 프로그램에서 담당했다. 이렇게 하려면 이 작업을 수행할 소프트웨어를 작성하고 유지보수할 프로그래밍 직원과 프로세스가 필요하다.
XML을 구현하는 과정에서 구조와 어휘를 확인하는 작업은 표준화되었으며 애플리케이션보다 앞서 진행된다. XML 문서는 잘 구성되어야 하며 공식 스키마 정의를 준수하는 경우에만 유효하다. 따라서 애플리케이션이 문서를 수신할 때 쯤에는 이 문서의 구조나 어휘가 올바르다고 인정된다. 이러한 확인 작업은 표준 컴포넌트를 사용하여 수행할 수 있다.
비즈니스 애플리케이션에서는 특정 정보 요소의 값을 확인하여 이 값이 유효한지 판별해야 하는 경우가 자주 있다. 이와 같은 값 확인 작업을 XML에 어떻게 통합할 수 있을까?
한 가지 방법은 열거형 목록으로 선언된 스키마를 사용하여 해당 값을 스키마로 인코드하는 것이다. 이 작업은 일반적으로 비즈니스 중심 스키마로 수행되지만 이러한 스키마는 유연성이 부족하다. 예를 들면, 목록 1은 현재 UBL 2.0 스키마에서 사용되는 UN/CEFACT(United Nations Centre for Trade Facilitation and Electronic Business) CCTS(Core Components Technical Specification) 통화 코드의 일부이다. 이 통화 코드는 유연하지 않은 관계로 UBL 2.1 스키마에서는 제거되었다.
목록 1. UN/CEFACT CCTS 통화 코드 일부
<xsd:simpleType name="CurrencyCodeContentType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="AED">
<xsd:annotation>
<xsd:documentation>
<ccts:CodeName>Dirham</ccts:CodeName>
<ccts:CodeDescription></ccts:CodeDescription>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="AFN">
<xsd:annotation>
<xsd:documentation>
<ccts:CodeName>Afghani</ccts:CodeName>
<ccts:CodeDescription></ccts:CodeDescription>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="ALL">
...
</xsd:restriction>
</xsd:simpleType>
|
여기에서는 CurrencyCodeContentType으로 사용할 수 있는 유효 값을 가능한 모두 열거한다. 또한, 어노테이션을 사용하여 코드가 의미하는 것을 문서화한다.
UBL 스키마에서 열거형 목록으로 구현된 다른 코드 목록은 두 가지뿐이다. 이러한 코드 목록은 BinaryObjectMimeCodeContentType의 MIME 인코딩 ID와
UnitCodeContentType의 유닛 코드 값이다. 모두 세 가지 열거형 목록을 UN/CEFACT 표준 코드 값 세트에서 가져왔으며 UBL 2.1 요구사항에서 사실상 이러한 목록이
충분히 안정하지 않다고 할 때까지는 이 목록은 열거형을 통해 삽입될 수 있을 정도로 완전하고 안정하다고 간주되었다.
스키마 내의 열거형 목록에 코드를 정의하면 코드를 변경하는 데 위험이 따른다. 또한, 변경된 내용을 반영하기 위해서는 표준 스키마를 수정해야 한다. 예를 들면,
체코슬로바키아(국가 코드: CS)가 두 개의 국가, 즉 체코 공화국(CZ)과 슬로바키아(SK)로 분리되는 경우와 같이 시간이 지나면서 국가 코드는 변경된다.
국가 코드 CS는 세르비아 몬테네그로 연방국에서 다시 사용하였다. 이러한 경우에는 수신 애플리케이션에 국가 코드 값을 명확하게 하기 위한 버전 번호와 같은
인스턴스 레벨 메타 데이터가 필요하다.
국가 코드의 경우, UBL 2.1이 릴리스된 시점의 코드 목록에서는 터키 리라에 TRY 값을 사용한 반면, UBL 2.0이 릴리스된 시점의 코드 목록에서는 같은 통화에
TRL 값을 사용했다. UBL 2.1 스키마에서는 모든 UBL 2.0 인스턴스의 유효성이 검증되어야 한다. UBL 2.1에서도 계속해서 통화에 하나의 열거형 목록을 사용했으면
터키 리라를 사용하는 UBL 2.0 인스턴스의 유효성이 검증되지 않았을 것이다. 간단한 열거형 목록에서는 공용체 구문을 사용할 수 있긴 하지만, 관련된 코드 목록 메타데이터의
CCTS 스펙에는 이렇게 사용하지 않도록 하고 있다.
이러한 간단한 실제 비즈니스 상황을 통해 스키마 기반 열거형 목록은 시간이 지나서 코드 목록을 유지보수하려면 문제가 발생한다는 사실을 확인할 수 있다. 비스키마 기반 열거형 코드 목록에 대한 UBL 2.0의 접근방식은 UBL 2.1에서는 모든 코드 목록으로 확장되었으며 스키마 기반 열거형 목록은 완전히 버려졌다.
스키마 내에 있는 열거형 목록은 로컬에서 관리하는 코드 목록의 경우에 문제가 된다. 스키마에서 로컬 코드 목록을 열거형 목록으로 구현하면 스키마를 특별한 용도로 사용할 때마다 표준 스키마를 수정해야 하고 표준 스키마는 존재하지 않게 된다. 이외에도 글로벌하게 정의된 정보 항목에는 다양한 문서 컨텍스트에서 여러 가지 값 세트가 있을 수 있다. 하나의 열거형 세트로는 이러한 요구사항을 충족시킬 수 없다.
UBL에서는 다소 고유한 접근방식을 취하여 그림 1과 같이 2단계 프로세스에서 사용할 스키마 외부에서 코드 목록을 구현한다. 구조와 어휘의 유효성 검증은 XSD 스키마를 사용하는 표준 방식으로 실행된다. 예를 들면, 송장은 UBL-Invoice-2.0.xsd를 준수하도록 구성되었을 수 있다. 인스턴스가 유효하면 이 인스턴스 값의 유효성이 검증된다. UBL은 이 단계에서 사용할 수 있는 표준 UBL 2.0 defaultCodeList.xsl 파일을 제공하지만, 일반 사용자는 이러한 목록을 서브세트로 나누고 확장하거나 새로운 코드 목록을 추가할 수 있다. 이 단계에서 인스턴스가 유효하면, 인스턴스는 후속 처리와 변환을 위해 애플리케이션에 전달된다. 이러한 과정을 통해 사용자는 표준 UBL 스키마를 변경하지 않고도 UBL 코드 목록을 최대한 유연하게 구성하고 업데이트할 수 있게 된다.
그림 1. 2단계 유효성 검증 프로세스
UBL은 글로벌한 느낌으로 비즈니스 문서를 처리하도록 설계된다. 전세계에 있는 거래 당사자를 조사하다 보면 수많은 요구사항을 알게 된다. 또한, 거래 당사자의 요구사항 간에는 상당한 차이가 있을 수 있다는 사실을 발견하게 된다. 거래 당사자에 특히 적합한 비즈니스 개념을 표현하는 일련의 값은 표준화되지 않았다. 거래 당사자는 그들의 로컬 요구사항을 지정해서 구현해야 하지만 모든 것은 UBL을 기반으로 글로벌하게 유지해야 한다.
거래 당사자는 비즈니스 규칙도 구현해야 한다. 예를 들면, 거래 당사자의 관계에서 특정 금액보다 더 큰 주문을 허용하지 않거나 특정 제품을 구매하는 경우에는 신용카드를 사용할 수 없게 할 수 있다. 또한, 거래 당사자가 비즈니스 규칙을 구현해야 하지만, 그 규칙은 전체적으로 UBL을 기반으로 작성되어야 한다. 이러한 비즈니스 규칙을 구현하는 한 가지 방법은 Schematron을 사용하는 것이다. (자세한 정보는 참고자료를 참조한다.)
애플리케이션에서는 UBL 문서의 유효성을 검증하는 이러한 2단계 과정을 어떻게 구현할 수 있을까?
UBL 릴리스 패키지의 val 디렉토리에 포함된 UBL 2.0 문서의 기본적인 유효성을 검증하기 위해 사용할 수 있는, 즉시 사용 가능한 오픈 소스 도구 콜렉션이 있다. 기본적인 유효성을 검증하는 과정에서는 현재 Linux나 Microsoft Windows® XP 시스템에 XML이나 XSLT 처리 소프트웨어가 설치되지 않았다고 가정한다. 또한, 유효한 문서, 철자가 잘못된 요소 이름이 있는 문서 그리고 구조와 어휘는 유효하지만 불법적인 코드 목록 값이 있는 인스턴스가 포함된 테스트 인스턴스가 포함된다. UBL 2.0 릴리스 패키지는 하나의 zip 아카이브로 다운로드할 수 있다. (링크는참고자료를 확인한다.)
코드 목록에 대한 스펙과 이러한 코드 목록과 특정 UBL 문서의 연관에 대한 스펙은 XML 문서를 통해 완성된다. 코드 목록은 제네릭코드(genericode)로 처리하지만, 연관 파일은 컨텍스트/값 연관(CVA)으로 처리한다.
OASIS Code List Representation Technical Committee에서는 OASIS Genericode 1.0을 개발했으며 제네릭코드를 다음과 같이 설명하고 있다.
- 코드 목록의 내용을 처리하는 데 필요한 표준 모델 및 XML 표현
- 코드 목록에 있는 항목과 연관된 데이터를 처리하는 데 필요한 표준 모델 및 XML 표현
CVA 파일에서는 거래 당사자의 범위 내에서 로컬 사용자 정의를 할 수 있다. 거래 당사자가 그들의 로컬 비즈니스 요구를 기반으로 수행하기를 원하는 것 중에는 다음과 같은 것들이 있다.
- 정보 엔티티 추가
- 선택적 정보 엔티티 생략
- 정보 엔티티의 의미 수정
- 정보 엔티티의 결합 또는 재결합 및 수집
- 문서 모델을 서브세트로 분리 - 문서에 있는 정보 엔티티의 수 제한
- 문서 내용의 제한 - 정보 엔티티에서 허용될 수 있는 값 제한
- 코드화된 목록과 같은 정보 엔티티에서 허용될 수 있는 값에 대한 제한조건 작성
- 비즈니스 규칙 추가
그러한 사용자 정의를 완성하는 데 필요한 전체 OASIS Guidelines 세트에 대한 링크는 참고자료를 참조한다. 그림 1을 참조하면 값의 유효성을 검증하는 작업이 XSLT 프로세스를 사용하여 실행된다는 점을 알 수 있다. UBL에서는 이러한 태스크를 완성하는 데 필요한 스타일시트를 프로그래밍 방식으로 생성한다.
코드 목록을 어떻게 정의할 수 있는지에 대한 예제인 목록 2는 CurrencyCodeContentType 열거형 목록(목록 1)에서 사용한 것과 같은 정보를 사용하여
제네릭코드로 코드화한 것이다.
목록 2.
CurrencyCodeContentType의 제네릭코드 버전
<?xml version="1.0" encoding="ISO-8859-1"?>
<gc:CodeList xmlns:gc="http://genericode.org/2006/ns/CodeList/0.4/">
<Identification>
<ShortName>CurrencyCode</ShortName>
<LongName xml:lang="en">Currency</LongName>
<LongName Identifier="listID">ISO 4217 Alpha</LongName>
<Version>2001</Version>
<CanonicalUri>urn:un:unece:uncefact:codelist:specification:54217
</CanonicalUri>
<CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:54217:2001
</CanonicalVersionUri>
<LocationUri>http://docs.oasis-open.org/ubl/os-ubl-2.0/cl/gc/cefact
/CurrencyCode-2.0.gc</LocationUri>
<Agency>
<LongName xml:lang="en">United Nations Economic Commission for Europe
</LongName>
<Identifier>6</Identifier>
</Agency>
</Identification>
<ColumnSet>
<Column Id="code" Use="required">
<ShortName>Code</ShortName>
<Data Type="normalizedString" xml:lang="en"/>
</Column>
<Column Id="name" Use="optional">
<ShortName>Name</ShortName>
<Data Type="string" xml:lang="en"/>
</Column>
<Key Id="codeKey">
<ShortName>CodeKey</ShortName>
<ColumnRef Ref="code"/>
</Key>
</ColumnSet>
<SimpleCodeList>
<Row>
<Value ColumnRef="code">
<SimpleValue>AED</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Dirham</SimpleValue>
</Value>
</Row>
<Row>
<Value ColumnRef="code">
<SimpleValue>AFN</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Afghani</SimpleValue>
</Value>
</Row>
<Row>
<Value ColumnRef="code">
<SimpleValue>ALL</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Lek</SimpleValue>
</Value>
</Row>
....
|
목록 2에서는 Identification을 사용하여 이 코드 목록에 관한 메타데이터를 일부 제공한다. ColumnSet에서는 두 개의 열(code와 name)을 정의하고
ID가 code인 열을 코드 목록에 삽입되는 키 값으로 사용할 수 있다고 표시한다.
그 다음 SimpleCodeList에서는 각 행에 코드 값과 코드의 해당 이름이 포함된 코드 목록의 내용을 정의한다.
이 코드 목록은 하나의 XML 문서로 정의되어 있다는 점에 유념한다. 이 문서에는 W3C 스키마가 들어 있다. 따라서 이 코드 목록 파일은 다른 XML 파일과 마찬가지로 승인될 수 있으며 유효성이 검증될 수도 있다.
OASIS에서는 다음과 같은 기본 CVA 파일 스펙을 제공한다.
"이 Committee Specification 01은 비즈니스 문서의 XML 인스턴스와 같은 구조화된 계층 구조에서 발견되는 정보 항목 간의 관계를 표현하는 데 사용하는 XML 어휘와 이러한 항목에 부과되는 두 가지 형태의 제한조건을 지정한다. 한 가지 제한조건은 값이 코드 목록이나 ID와 같은 열거형 값으로 구성된 제어된 어휘 세트의 멤버이어야 하는 것이다. 또 다른 형태의 제한조건은 최대 문자열 값 길이와 같은 이중 어휘 제한조건이나 비즈니스 규칙 및 비열거형 코드 목록 값 확인(ISBN 번호의 체크섬 계산)과 같은 부울 쿼리 표현식을 임의로 평가하는 것이다." (OASIS Committee Specification 01 링크는 참고자료를 참조한다.)
목록 3은 PaymentMeansCode CVA 파일의 다양한 기능을 설명하기 위해 CVA 파일에서 가져온 스니펫이다.이 CVA 파일은 스키마가 있는 XML 파일이며 따라서
다른 XML 파일과 마찬가지로 승인될 수 있으며 유효성이 검증될 수도 있다. 이 파일에서는 UBL 문서에서 다양하게 존재하는 PaymentMeansCode를 올바른 코드 목록과
연관시켜서 그 값의 유효성을 검증한다.
목록 3. CVA 파일의 다양한 기능
<?xml version="1.0" encoding="UTF-8"?>
<cva:ContextValueAssociation xmlns:cva="http://docs.oasis-open.org/codelist/ns
/ContextValueAssociation/1.0/"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd
:CommonBasicComponents-2"
xmlns:x="http://www.w3.org/1999/xhtml"
name="UBL-QualifiedDataTypes-2.0"
version="2010-08-30 20:21:05(UTC)"
id="urn:oasis:names:specification:ubl:cva:UBL-Qualified
-Data-Types:2">
<Annotation>
<Description>
<x:p>
This describes all of the qualified supplementary components and
business information entities for the OASIS Universal Business
Language (UBL) 2.0 vocabulary.
</x:p>
<x:p>
In UBL 2.1 qualified data types are anonymous (in that they are
not expressly named or identified) and UBL information items with
qualifications are addressed in this document and associated with
their respective value qualifications.
</x:p>
<x:p>
At this time all value qualifications are Code Lists, which are
a type of value list (the other type being identifier lists).
Instance metadata for UBL is described by the UN/CEFACT Core Component
Technical Specification (CCTS) Version 2.01.
The document contexts are all of the supplementary components and
business entities in a UBL instance that have qualified values.
</x:p>
</Description>
</Annotation>
<Title>
UBL 2.0 and UBL 2.1 qualified information items
</Title>
<ValueLists>
<Annotation>
<Description>
<x:p>
These list all of the genericode files of Code Lists used by
UBL information items whose values are qualified by Code Lists.
</x:p>
<x:p>
The unique identifier <x:samp>xml:id=</x:samp> is used later in
this file when describing the context for each entity that has
a qualified value.
</x:p>
<x:p>
The URI value points to the genericode file associated with the
identifier. The URI is hyperlinked in this report to a rendering
of the contents of the genericode file that follows the rendering
of the contexts.
</x:p>
</Description>
</Annotation>
...
<ValueList xml:id="PaymentMeans-2.0"
uri="../../os-UBL-2.0/cl/gc/default/PaymentMeansCode-2.0.gc"/>
<ValueList xml:id="PaymentMeans-2.1"
uri="../cl/gc/default/PaymentMeansCode-2.1.gc"/>
...
</ValueLists>
<Contexts>
<Annotation>
<Description>
<x:p>
The contexts in which various items with a qualified value
are specified.
</x:p>
<x:p>
The <x:samp>address=</x:samp> attribute is an XPath address that
satisfies all of the UBL items in the instance that are qualified
with the indicated value lists using the indicated associated set
of instance-level metadata items.
</x:p>
<x:p>
Each context identifies the collection of supplementary components
(by its identifier) where instance-level metadata is found, then
all value lists (by their identifier) that apply to the item being
addressed.
</x:p>
<x:p>
The contexts are listed first for attribute items and then for
element items.
</x:p>
</Description>
</Annotation>
...
<Context values="PaymentMeans-2.0 PaymentMeans-2.1"
metadata="cctsV2.01-code"
address="cbc:PaymentMeansCode"/>
...
<Context values="Currency-2.0 Currency-2.1"
metadata="cctsV2.01-code"
address="cbc:DocumentCurrencyCode |
cbc:TaxCurrencyCode |
cbc:PricingCurrencyCode |
cbc:PaymentCurrencyCode |
cbc:PaymentAlternativeCurrencyCode |
cbc:RequestedInvoiceCurrencyCode |
cbc:SourceCurrencyCode |
cbc:TargetCurrencyCode |
cbc:CurrencyCode"/>
...
</Contexts>
</cva:ContextValueAssociation>
|
ValueLists 섹션에는 두 개의 PaymentMeans 항목이 있으며 각 항목은 버전 번호가 각각 2.0과 2.1이다. 이렇게 되면 UBL 버전을 기반으로 정보를 참조할 수 있다.
PaymentMeansCode의 컨텍스트 목록에서 XPath cbc:PaymentMeansCode는 이 참조가 PaymentMeansCode에 적합한 것이고 UBL 문서 2.0과 2.1 모두에서 표시된다는 것을 의미한다.
UBL 문서에서 특정 위치나 다수의 위치를 참조할 수 있다. 예를 들어, 통화와 관련된 예제를 살펴보자. 이 예제는 다양한 통화 코드로 구성된
공용체(DocumentCurrencyCode 및 TaxCurrencyCode)와 연관되어 있다.
실제 PaymentMeansCode 코드 목록은 목록 4에 표시되어 있으며 제네릭코드 파일에도 지정되어 있다. (참고자료를 참조한다.)
목록 4.
PaymentMeansCode 코드 목록
<?xml version="1.0" encoding="UTF-8"?>
<gc:CodeList xmlns:gc="http://docs.oasis-open.org/codelist/ns/genericode/1.0/">
<Identification>
<ShortName>PaymentMeansCode</ShortName>
<LongName xml:lang="en">Payment Means</LongName>
<LongName Identifier="listID">UN/ECE 4461</LongName>
<Version>D03A</Version>
<CanonicalUri>urn:oasis:names:specification:ubl:codelist:gc:
PaymentMeansCode</CanonicalUri>
<CanonicalVersionUri>urn:oasis:names:specification:ubl:codelist:gc:
PaymentMeansCode-2.0-update</CanonicalVersionUri>
<LocationUri>http://docs.oasis-open.org/ubl/os-UBL-2.0-update/cl/gc
/default/PaymentMeansCode-2.0.gc</LocationUri>
<Agency>
<LongName xml:lang="en">United Nations Economic Commission for
Europe</LongName>
<Identifier>6</Identifier>
</Agency>
</Identification>
<ColumnSet>
<Column Id="code" Use="required">
<ShortName>Code</ShortName>
<Data Type="normalizedString"/>
</Column>
<Column Id="name" Use="optional">
<ShortName>Name</ShortName>
<Data Type="string"/>
</Column>
<Key Id="codeKey">
<ShortName>CodeKey</ShortName>
<ColumnRef Ref="code"/>
</Key>
</ColumnSet>
<SimpleCodeList>
<Row>
<Value ColumnRef="code">
<SimpleValue>1</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Instrument not defined</SimpleValue>
</Value>
</Row>
<Row>
<Value ColumnRef="code">
<SimpleValue>2</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Automated clearing house credit</SimpleValue>
</Value>
</Row>
...
<Row>
<Value ColumnRef="code">
<SimpleValue>20</SimpleValue>
</Value>
<Value ColumnRef="name">
<SimpleValue>Cheque</SimpleValue>
</Value>
</Row>
...
</SimpleCodeList>
</gc:CodeList>
|
이 목록을 자세히 살펴보면 지불 수단으로 구성된 다양한 배열을 찾을 수 있다. UBL은 국내외에서 이루어지는 거래에 맞게 글로벌하게 사용되도록 설계되기 때문에 가능한 모든 비즈니스 요구사항을 다루어야 한다. 또한, 로컬 비즈니스 요구사항에 맞는 이 목록을 서브세트로 나눌 수 있다. 모든 사용자가 이러한 꺾쇠괄호 파일을 편하게 느끼는 것은 아니다. 다행히도 이러한 파일은 모두 XML 파일이다. 따라서 XSLT를 사용하여 HTML로 변환하거나 XSL-FO를 사용하여 공식적인 프린트 파일이나 PDF 파일로 변환할 수 있다(참고자료 확인).
예를 들면, XSLT 스타일시트를 사용하여 위에 있는 제네릭코드 파일을 코드 목록과 같은 연관된 XML 파일에 동반되는 모든 XML 요소, 값 및 속성이 표시된
읽을 수 있는 HTML 보고서로 변환할 수 있다. 위에 있는 제네릭코드 파일을 변환하여 생성된 HTML 결과물을 확인하려면 참고목록에 있는
"Contexts" 항목을 참조한다. 이 보고서에서 PaymentMeansCode가 목록 5와 같이 표시된다는 것을 알 수 있다.
목록 5. 결과물
address="cbc:PaymentMeansCode" instance metadata set: cctsV2.01-code value list: PaymentMeans-2.0 (detail) value list: PaymentMeans-2.1 (detail) |
cctsV2.01-code, PaymentMeans-2.0, PaymentMeans-2.1 및 (detail)은 보고서에서 빠른 탐색이 가능한 부분의 핫 링크이다. 그리고 보고서를 더 살펴보면
UBL로 100가지 지불 수단을 세부적으로 기술한 HTML 테이블을 확인할 수 있다. 이 보고서를 작성하기 위해 이 위원회에서 사용한 스타일시트는 Crane Softwrights Ltd.에서 무료로
다운로드할 수 있다(참고자료 확인)
앞서 언급한 바와 같이 값의 유효성을 검증하는 2단계 과정에서 사용한 스타일시트는 프로그램 방식으로 생성된다. 그림 2에서 Assertion validation stylesheet(2)는 Context/value association(CVA), External value list expression(GC) 및 Business rule(SCH)을 이용하여 구성된다. 이러한 모든 문서는 표준 XML 문서이며 표준 XML 처리 소프트웨어를 이용하여 처리할 수 있다. 실제로 표준 XSLT 스타일시트를 생성할 수 있으며 이 스타일시트를 XML 문서를 대상으로 처리하면 XML 문서의 내용이 유효한지 그리고 비즈니스 규칙을 충족시키는지 그 유효성을 검증할 수 있다.
그림 2. 값의 유효성 검증
그림 2에는 거래 당사자의 비즈니스 요구를 표현하는 다음과 같은 세 가지 유형의 입력이 있다.
- Context/value associations(3)는 제네릭코드로 표현되며 이 경우에는 소스 XML 문서에 있는 정보 엔티티의 컨텍스트를 기반으로 값의 유효성을 검증할 수 있다. 특정 정보 엔티티는 XPath 표현식을 사용하여 표현한다.
- External value list expressons(4)는 제네릭코드로 표현되며 제어된 어휘이다.
- Business rules(5)는 Schematron으로 표현된다.
거래 당사자는 대부분 특정 상황에 들어맞아야 하는 로컬 조건을 설정하고 싶어한다. 이러한 조건이 특정 거래 당사자에게 적용되는 비즈니스 규칙이다.
UBL에서는 이러한 조건을 ISO/IEC 19757-3 Schematron 배치를 사용하여 지정할 수 있다. Schematron 파일은 UBL 문서에 관한 검증 세트로 유효성을 테스트하는 데 사용된다. Schematron은 XML Schematron 어휘를 사용하여 표현한다. (Schematron에 대한 자세한 정보를 확인할 수 있는 링크는 참고자료를 참조한다.)
Python으로 구현하는 것이 가능하지만 일반적으로 Schematron은 XSLT를 사용하여 구현한다. XSLT를 사용하여 구현하는 경우, 값의 유효성을 검증하는 두 번째 단계에서 사용한 XSLT 스타일시트는 제네릭코드 파일과 CVA 파일, Schematron 파일을 사용하여 프로그램 방식으로 생성한다. 이렇게 생성된 스타일시트를 유효한 UBL 문서를 대상으로 적용하면 값 오류가 UBL 파일에 기록된다.
OASIS UBL을 예제 어휘와 구현으로 사용하여 XML 문서의 코드 목록 요소에 대한 개요를 소개했다. UBL 문서의 유효성을 검증하는 과정에는 W3C XSD를 사용하여 UBL 문서의 구조와 어휘의 유효성을 검증하는 과정뿐만 아니라 UBL 문서에 있는 다양한 정보 요소 내용의 값을 검사하는 과정이 포함되어 있다. 사용할 수 있는 기본 코드 목록이 UBL 릴리스 패키지에 포함되어 있기는 하지만, 코드 목록 기술에는 거래 당사자가 로컬에서의 특정 요구에 맞춰 이러한 코드 목록을 사용자 정의하고 이를 기반으로 비즈니스 규칙을 구현할 수 있게 하는 자원과 지침이 포함되어 있다. 코드 목록 기술을 UBL과 함께 설명했지만, 이 기술을 다수의 도메인에서 모든 XML문서, 특히 XML 비즈니스 문서와 함께 사용할 수 있으며 여기에서 UBL은 단지 하나의 사례에 불과하다. 코드 목록 기술을 사용하는 두 가지 사례로는 뉴질랜드 교육부와 FpXML을 들 수 있다.
교육
-
UBL and Disruptive Innovation: Out-of-the-box business XML for multiple industries(Hugh Chatfield, developerWorks, 2010년 11월): UBL에 대한 멋진 소개,
비즈니스 문서 작성상의 UBL의 가치, UBL을 사용하는 몇 가지 예제 그리고 UBL이 파괴적 혁신인 이유에 대한 설명이 있는 또 다른 기사를 읽어보자.
-
UBL 2 Guidelines for Customization, First Edition: 사용자 정의에 필요한 전체 OASIS Guidelines 세트를 확인하자.
-
Context/value association using genericode 1.0: Committee Specification 1.0: 컨텍스트/값 연관에 필요한 전체 OASIS 스펙을 읽어보자.
-
A Hands-on introduction to Schematron(Uche Ogbuji, developerWorks, 2004년 9월): 이 기사에서 Schematron에 대한 우수한 개요를 읽어보자.
-
OASIS Universal Business Language(UBL) Technical Committee
-
OASIS Code List Representation Technical Committee
-
통화 코드 목록: 코드 목록 값이 포함된 CurrencyCodeContentType 스키마를 확인하자.
-
Appendix E. UBL 2.0 Code Lists and Two-phase Validation(Informative): UBL 2단계 유효성 검증에 대한 간단한 소개를 읽어보자.
-
CVA 파일 — HTML 변환: 이것은 UBL 2.0과 UBL 2.1 규정된 정보 항목을 기본 HTML로 변환한 것이다.
-
UBL용 CVA: UBL용의 완전한 CVA 파일이다.
-
제네릭코드 구현: 알려진 제네릭코드의 구현 목록을 검토하자.
-
UBL FAQ: UBL FAQ를 통해 배우자.
- PaymentMeansCode: 제네릭코드 파일에 지정된 PaymentMeansCode의 완전한 코드 목록을 확인하자.
-
컨텍스트: XML 파일을 HTML로 변환하는 예제를 통해 자세히 배우자.
-
CCTS(2003) — Core Components Technical Specification — Part 8 of the ebXML Framework: ebXML의 개념을 해석하거나 구현하는 데 필요한 안내 정보를 검토하자.
-
Cover Pages: XML 형태의 마크업 언어 표준을 지원하는 포괄적인 온라인 참조 콜렉션인 Cover Pages에서 UBL에 관해 자세히 배우자.
-
Crane Softwrights — UBL 2.0 Model Summary Reports: 정보 항목과 문서 모델 스프레드시트가 요약되어 있고 각각 3MB 정도로 압축된 61개의 HTML 파일 세트를 이용하자. Crane Softwrights Ltd.는
1997년 이후로 전세계에서 컴퓨터 시스템 분석과 교육 서비스를 제공하는 컨설팅 회사이다.
-
OASIS UBL TC — UBL 2 Guidelines for Customization: UBL 준수 및 UBL 호환 문서 스키마를 작성하는 데 필요한 실용적인 안내서를 이용하자.
-
OASIS(2006) — UBL 2.0 — 샘플 UBL 문서: 송장, 주문서 및 주문 응답과 같은 UBL 문서에 대한 예제를 통해 UBL에 관해 자세히 배우자.
-
IBM developerWorks Industry Zone: 개발자에게 필요한, 산업에 특화된 모든 최신 기술 자료는 이 사이트를 참조한다.
-
developerWorks
팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
-
developerWorks
기술 행사 및 웹 캐스트: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
제품 및 기술 얻기
-
IBM 시험판 소프트웨어: 다운로드하거나 DVD로 제공받을 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 오픈 소스 개발 프로젝트를 구현해 보자.
토론
-
developerWorks 블로그: developerWorks 커뮤니티에 참여하자.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그