-- WisitWongwilai - 18 Apr 2008

XML Naming and Design Rules

XML Schema Desigin with ebXML Core Components (ISO 15000-5)

CCTS and BIE

การใช้ Core Components มาใช้ในการออกแบบเอกสารจะสร้างความมั้นใจได้ว่าระหว่างองค์กรสององค์กรที่อาจมีการใช้โครงสร้างของเอกสารทีไม่เหมือนกัน เช่น เอกสารประเภท Extensible Markup Language (XML) และ United Nations/EDI หรือ UN/EDIFACT นั้นยังมีเนื่อหาสาระของข้อมูลทางธุรกิจเหมือนกัน และจะสามารถจัดการกับเอกสารที่มีการแลกเปลี่ยนกันในรูปแบบต่างๆ ในกลุ่มธุรกิจ หรือระหว่างกลุ่มธุรกิจได้

Key Core Component Concepts

จุดประสงค์หลักของการนำใช้ Core Component คือการนำ Core Component มาใช้งานในการสร้างเอกสารอิเล็กทรอนิกส์ทางธุรกรรมที่มีอยู่ในรูปแบบต่างๆ Core Components มีการจัดแบ่งประเภทออกเป็น 4 ประเภทได้แก่

• Basic Core Component (BCC)
• Association Core Component (ASCC)
• Core Component Type (CCT)
• Aggregate Core Component (ACC)

จากรูปตัวอย่างจะมี Aggregate Core Components อยู่ 2 Components ได้แก่ Person. Details และ Address. Details โดยในแต่ละ Aggregate Core Components จะมีข้อมูลที่อธิบายตัวเองอยู่ (Properties) เช่นใน Person. Details จะมี Properties อยู่ 4 ค่าด้วยกันได้แก่ Name, Birth Date, Residence Address และ Official Address ส่วน Aggregate Core Components Address. Details จะมีค่า Properties อยู่ 4 ค่า ได้แก่ Street, Post Code, Town, Country

โดยส่วนใหญค่า Properties จะเป็น Basic Core Components ถ้าหาก properties ได้อธิบายค่าที่ตัวเองเก็บโดยตรง และจะตามด้วยประเภทของข้อมูลที่จัดเก็บ Data Type เช่น ประเภทข้อมูของ Name, Street, Post Code และ Town จะเป็น Data Type ประเภท Text ส่วน Birth Date จะมี Data Type เป็นประเภท Date และ Country จะมี Data Type เป็นประเภท Identifier เป็นต้น และ Properties ของอีกประเภทหนึ่งได้แก่ Association Core Components คือ properties ที่อธิบายค่าที่มีโครงสร้างซับซ้อน (Complex business characteristics) จากตัวอย่างได้แก่ Residence Address และ Official Address จะเป็น Association Core Components ที่อธิบายตามโครงสร้างโดย Address. Details

ดังนั้นจากตัวอย่างเราจะได้กลุ่มของ Core Components ดังต่อไปนี้

Core Component Type (CCT)

รูปแบบประเภท Core Component Type คือประเภทที่เก็บค่าข้อมูลจริงๆ และอาจจะมีการอธิบายข้อมูลนั้นเพิ่มเติมด้วย Supplementary Components แต่ Core Component Types จะไม่ได้แสดงว่าเป็นข้อมูลของประเภทธุรกิจใด ตัวอย่างของ Core Component Type เช่น Amount. Type จะเป็นประเภทข้อมูลที่สามารถแสดงข้อมูลเป็นตัวเลขจำนวนเงิน แต่จะไม่ได้บอกว่าจำนวนเงินนี้ใช้สำหรับอธิบายของค่าอะไรในเอกสาร เช่นมีค่าเท่ากับ 12 หรืออาจจะมีการอธิบายข้อมูลเพิ่มเติมด้วยค่า Supplementary ว่าเป็นเงิน Baht หรือเงิน Euro เป็นต้น

Aggregate Core Component (ACC)

ประเภทข้อมูล Aggregate Core Component จะเป็นการรวมกันของชนิดข้อมูลที่อธิบายข้อมูลทางด้านธุรกิจ โดยชื่อของ Aggregate Core Component จะขึ้นอยู่กับประเภทธุรกิจนั้นๆ ว่าใช้คำศัพท์อะไรสำหรับการอธิบาย และ Aggregate Core Component จะแสดงอยู่ในรูปบบคลาส (Object Class)

ตัวอย่างของ Aggregate Core Component เช่น Financial_Account. Details คือ ข้อมูลที่ธนาคาร หรือสภาบันการเงิน ที่ให้บริการด้านการเงินแก่ลูกค้าซึ่งประกอบด้วยค่า Properties ต่างเพื่ออธิบายข้อมูลที่ Financial Account เช่นอาจประกอบด้วย

Basic Core Components (BCC)

• Financial_Account. Identification .Identifier
• Financial_Account. Name. Text
• Financial_Account. Country. Identifier
• Financial_Account. Product Type. Identifier

Data Type (DT)

Data Type จะเป็นตัวบอกประเภทของข้อมูลใน Core Component Property โดย Data Type จะขั้นอยู่กับ Core Component Type แต่จะสามารถเพิ่มข้อจำกัดของข้อมูล (Restrictions) จาก Content Component หรือ Supplementary Component(s) ใน Core Component เพื่อให้มีความเหมาะสมกับข้อมูลที่จะอยู่ข้างในเอกสาร XML

แผนภาพแสดงประเภทและความสัมพันธ์ ของ Core Component elements

Business Information Entity (BIE) และ Core Components

ความแตกต่างระหว่าง Business Information Entity และ Core Components คือ การนำเอา Core Components มาใช้สำหรับแต่ละธุรกิจหรือสำหรับประเภทกลุ่มการทำงานหนึ่ง โดยมีการเสริมด้วยคำขยายความ (Qualifying) หรือทำให้ Core Components นั้นให้เหมาะสมกับการใช้งานยิ่งขึ้น ดังนั้น Business Information Entity จึงเป็นการนำเอา Core Components มาใช้สำหรับอธิบายเอกสารหนึ่งที่เฉพาะกับกลุ่มทางด้านธุรกิจหนึ่งๆ โดยเฉพาะ

Business Information Entity (BIE)

Business Information Entity (BIE) ใช้สำหรับอธิบายกลุ่มของข้อมูลที่ใช้สำหรับธุรกิจหนึ่งๆ โดย Business Information Entity อาจเป็น Basic Business Information Entity (BBIE) Association Business Information Entity (ASBIE) หรือ Aggregate Business Information Entity (ABIE)

Basic Business Information Entity (BBIE) จะอธิบายคุณสมบัติพื้นฐานของเอกสาร ที่มีการเก็บค่าที่แท้จริงตามประเภทข้อมูล (Data Type) ที่ได้กำหนดไว้ ดังนั้น Basic Business Information Entity จึงเป็นประเภทข้อมูลที่มีรากฐานมาจาก Basic Core Component

ส่วน ข้อมูลประเภท Association Business Information Entity (ASBIE) จะมีรากฐานมากจาก Association Core Component (ASCC) และ Aggregate Business Information Entity (ABIE) จะมีรากฐานมาจาก Aggregate Core Component (ACC) ดังแสดงในรูปความสัมพันธ์ระหว่าง Business Information Entities และ Core Components

ความสัมพันธ์ระหว่าง Core Components และ Business Information Entities

การสร้างเอกสารอธิบายโครงสร้าง XML Schema จาก Core Component Model

1. Component ที่เป็นประเภท ABIE หรือ ACC เช่น Person. Details ให้กำหนดเป็นชนิดข้อมูลแบบ Complex types ใน XML Schema
2. ข้อมูลที่เป็น Properties (BCC, ASCC, BBIE, ASBIE) เช่น Person. Name. Text จะกำหนดเป็น Element ที่มีการอ้างอิง Type ของตัวเอง
3. ในส่วนของ Representation terms เช่น Text, Date และ Address จะกำหนดเป็น Types ตามแต่ชนิดของข้อมูล
   
   

การกำหนดชนิดจาก Dictionary ไปยังการกำหนดชื่อในเอกสาร XML

1. ตัดชื่อที่มีความซ้ำซ้อนกันออก เช่น Identification. Identifier
2. ลบจุด เว้นวรรค และ ขีดเส้นใต้ ออก
3. เปลียนคำจาก Details เป็น Type
4. ถ้า Representation term เป็น Text ให้ตัดคำว่า Text ออก
5. ถ้า Representation term เป็น Identifier ให้ใช้ ID แทน
6. เอาชื่อคลาสที่นำหน้า Properties ออก
   
   นำโครงสร้างของคลาสที่ได้มาเขียน XML Schema สำหรับการอธิบายโครงสร้างเอกสาร XML โดยรูปแบบการเขียน XML Schema

XML Schema Models(อ้างอิงจาก UK e-Gif และ UBL)

ในการเขียนเอกสาร XML Schema นั้นสามารถเขียนได้หลายรูปแบบตั้งแต่อยู่ในรูปแบบเป็นลำดับชั้นซ้อนกัน (Hierarchical style) และจนกระทั้งรูปแบบที่มีลำดับชั้นน้อย (Very flat style) อย่างไรก็ตามรูปแบบการเขียน XML Schema นั้นจะมีวิธีแบบใดขึ้นอยู่กับการนำไปใช้งานนั้นๆ มากกว่า

รูปแบบการเขียนแบบ Russian Doll model

การเขียนในรูปแบบ Russian Doll จะประกาศในทุก Element เป็นแบบ local ทั้งหมดดังนั้นจะทำให้ Schema มีโครงสร้างเป็นแบบลำดับชั้นซ้อนกัน (Hierarchical style) ข้อดีของการเขียนแบบ Russian Doll คือเขียนได้ง่ายรวดเร็ว แต่ข้อเสียคือจะมีความซ้ำซ้อนของ Element ในตัวเอกสารมาก ไม่สามารถนำ Element มีสร้างขึ้นไปใช้งานได้อีก (Re-use) ดังนั้นจึงไม่เหมาะสมสำหรับนำมาใช้อธิบายเอกสารที่ต้องการสร้างความสอดคล้องของเอกสาร (Harmonization)

จากตัวอย่าง Element Name จะมี Element ย่อยอยู่ 2 ตัวด้วยกันได้แก่ Forename และ Surname โดยในแต่ละ Element ย่อยจะมีคุณสมบัติของตัวเองที่มีค่าเหมือนกันคือ เป็น Type xs:string และสามารถมีข้อมูลที่มีความยาวตั้งแต่ 1 ถึง 35 ตัวอักษร

รูปแบบการเขียนแบบ Salami Slice model

รูปแบบการเขียน XML แบบมีโครงสร้างลำดับชั้นซ้อนกัน (Hierarchical style) อีกรูปแบบหนึ่งได้แก่ Salami Slice แต่ Salami Slice จะกำหนดให้แต่ละ Element เป็นแบบ Global เพื่อให้ง่ายต่อการแยกย่อยเป็นเอกสาร XML ในภายหลัง

จากตัวอย่างจะเห็นว่า Element Forename และ Surname เป็น Element แบบ Global และในตัว Element Name จะใช้การอ้างอิงไปยัง Element ทั้งสองอีกทีหนึ่ง แต่อย่างไรก็ตามในตัว Forename และ Surname จะมีคุณสมบัติของตัวเองอยู่ที่มีค่าเหมือนกันเช่นเดียวกับ Russian Doll แต่จะสามารถถูกนำไปใช้โดยการอ้างอิงจาก Element อื่นได้ (Re-use)

รูปแบบการเขียนแบบ Venetian Blind model

รูปแบบการเขียน Venetian Blind จะมีส่วนคล้ายกับ Salami Slice มากเพียงแต่ใน Venetian Blind แทนที่จะกำหนดใน Element ย่อยเป็น Global element จะกำหนดเป็น Global type แทน

จากตัวอย่าง Forename element จะเป็น element ประเภท ForenameType^? และ Surname element จะเป็น element ประเภท SurnameType^? ดังนั้นการเขียน XML Schema ในรูปบบ Venetian Blind จะสามารถนำประเภท (Type) ไปใช้ได้อีก โดยให้ Element มาอ้างอิงประเภทที่ประกาศไว้เป็น Global

รูปแบบการเขียนแบบ Garden of Eden model

สำหรับรูปแบบการเขียนแบบ Garden of Eden นั้นจะเป็นการรวมกับระหว่างรูปแบบ Salami Slice และ Venetian Blind โดยจะกำหนดให้ทั้ง Elements และ Type เป็น Global ทั้งหมด ทำให้ Garden of Eden มีรูปแบบลำดับชั้นน้อย หรือ flat style มากที่สุดทำให้สามารถนำ Element หรือ Type ไปใช้ได้อีกโดยการอ้างอิง

สรุป

จาก Model ทั้ง 4 จะเห็นว่า Venetian Blind model และ Garden of Eden model มีความเหมาะสมสำหรับการเขียน XML Schema ที่ต้องการ Re-used มากที่สุด
แต่จะใช้ Model ใดทาง UK e-Gif และ UBL ไม่ได้บอกชัดเจน แต่ใน UN/CEFACT Naming and Design Rules Version 2.0 ได้มีการกำหนดอย่างชัดเจนในการ
Mapping จาก Object Model (BIE) --> XML Schema โปรดติดตามตอนต่อไปนะครับ

XML_NDR.pdf: XML NDR

References