Розділ 3. Удосконалення процесів застосування гармонізованих стандартів на базі xml-технологій

3.1. Застосування новітніх інформаційних технологій для поліпшення нормативної документації

Сучасний розвиток інформаційних технологій набуває особливого значення для процесів розроблення стандартів.

Особливе місце в практиці стандартизації займають питання розробки XML-специфікацій. Сьогодні навряд чи хто-небудь стане оспорювати значення XML-технологій. Завдяки мові розширюваної розмітки стало можливим розвиток електронної комерції по схемі "бізнес-бізнес" (B2B). Що не як XML, ключовою особливістю якого є незалежність від платформи, може забезпечити можливість взаємодії програмних і апаратних засобів різних постачальників? На думку фахівців аналітичний компанії IDC, для електронного бізнесу XML вже став стандартом де-факто.

Крім того, XML став базисом для розвитку багатьох інших мов програмування, призначених для вирішення прикладних завдань (наприклад, XLink, XPointer, XSLT ), і галузевих діалектів XML (FpML, OFX/IFX, FinXML, ebXML, MathML, XBRL ), використовуваних в різних сегментах економіки або напрямах бізнесу.

Нарешті, такі популярні нині Web-сервіси просто неможливі без XML. Будучи універсальним механізмом обміну, XML створює всі передумови для створення незалежної від платформи моделі Web-сервісів.

При цьому дуже важливою являється роль організацій, що займаються стандартизацією самої мови XML, його діалектів і XML-технологій. У жодному випадку не намагаючись зменшити гідності інших органів стандартизації можна виділити дві ключові фігури в області розробки стандартів

XML-технологій: міжнародні консорціуми W3C і OASIS .

Слід зазначити, що членами цих співтовариств є провідні компанії на ринку інформаційних технологій: IBM, Intel, Microsoft, Oracle, SAP та інші - що зайвий раз свідчить про серйозність специфікацій, що затверджуються в цих консорціумах.

Отже процеси стандартизації в різних організаціях можуть дещо відрізнятися, але в цілому простежується певна спільність підходів. При цьому значущість документів, що регламентують порядок ухвалення стандартів певним чином впливає на успішне завершення робіт над стандартом.

3.2. Методика розробки стандарту в форматі консорціуму w3c

Перш ніж розробити стандарт, консорціум W3C формує ідею цього стандарту. Етап формування Ідеї в міжнародній організації W3C починається з висунення пропозиції про ініціалізацію нового напряму діяльності (Activity). До такої пропозиції штатні співробітники консорціуму (W3C Team) можуть прийти в ході здійснення своєї діяльності: проведення конференцій і семінарів, відстежування тенденцій у області Web-технологій і т.п. В цьому випадку директор (Director) направляє відповідну заявку в консультативний комітет (Advisory Committee). Протягом періоду розгляду консультативний комітет висловлює свої міркування і зауваження з обговорюваного питання, після чого директор інформує комітет про відношення членів консорціуму до цієї пропозиції. При наявність консенсусу, тобто, якщо ця ідея одержує загальну підтримку, створюється новий напрям.

Організаційно, всі роботи в консорціумі будуються навколо таких напрямів. Цілі і завдання кожного напряму висловлюються в Декларації напряму (Activity statement), в якому приводиться список задіяних робочих груп (Working Group). Саме в цих групах виконується левова частка роботи консорціуму - результатом їх діяльності є технічні звіти, програмні засоби з відкритим кодом і інші послуги.

Слід зазначити, що технічний звіт, який публікує робоча група, по суті є однією з можливих версій стандарту, що розробляється, а саме: робочою версією (Working Draft), останньою редакцією робочої версії, або робочою версією в статусі "крайнього терміну" (Last Call Working Draft), кандидатом до рекомендації (Candidate Recommendation), запропонованою рекомендацією (Proposed Recommendation) або рекомендацією (Recommendation).

Робоча версія являється "першим кроком" в просуванні технічного звіту до найвищого статусу, який може одержати специфікація тобто рекомендації. Формально, для публікації робочої версії необхідна згода директора, хоча факт обнародування документа не є віддзеркаленням наявності консенсусу або схвалення із сторони W3C. При цьому, робоча група має право запросити видання робочої версії, навіть якщо її текст не є остаточним і не відповідає всім вимогам групи.

Після виходу робочої версії група повинна продовжити над нею роботу: приймати коментарі і зауваження до даного документа як від членів W3C, так і розробників і користувачів, що не входять до складу консорціуму.

Остання редакція робочої версії − "особливий випадок" робочої версії. Цей документ є результатом її доопрацювання на предмет відповідності вимогам робочої групи, а також формального дозволу всіх питань, що виникли в процесі її вивчення як самими її авторами, так і іншими робочими групами і "представниками громадськості". Представляючи специфікацію в цьому статусі, робоча група розсилає запит на участь в розгляді документа, фактично очікуючи одержати підтвердження про відсутність значних заперечень. При цьому, робоча група повинна встановити період прийому коментарів.

На цьому етапі до роботи над специфікацією підключається консультативний комітет, який всіляко сприяє обговоренню даного документа − для того, щоб виявити всі проблеми і питання до того, як специфікація перейде в статус кандидата до рекомендації.

Після закінчення "остаточного терміну" робоча група може звернутися до директора з проханням надати специфікації статус кандидата до рекомендації або запропонованої рекомендації. У разі відмови, директор зобов'язаний "знизити" документ до робочої версії, повідомивши про це всі групи W3C.

Для отримання статусу кандидата до рекомендації, робоча група повинна виконати всі вимоги, що пред'являються до останньої редакції робочої версії, тобто формально відповісти по всіх "претензіях", що виникли під час періоду "крайнього терміну", а також погодити всі питання, які відносяться до ведення інших груп.

При переході останньої редакції робочої версії до кандидата до рекомендації директор направляє в консультативний комітет запит на реалізацію даної специфікації. Фактично, перехід специфікації в даний статус, означає, що робоча група чекає, що запропонований нею документ знайде практичне застосування.

Як і у випадку з останньою редакцією робочої версії, після закінчення "кандидатського" періоду робоча група може звернутися до директора з проханням надати специфікації статус запропонованої рекомендації. У разі відмови, директор зобов'язаний "знизити" документ до робочої версії, повідомивши про це консультаційний комітет.

Для отримання статусу запропонованої рекомендації робоча група повинна виконати всі вимоги попереднього етапу, а також добитися реалізації кожної функціональності, представленої в специфікації. Бажано, щоб на кожну функціональність були хоч би два не зв'язані між собою випадки її реалізації. Проте, якщо директор вважає, що негайне вивчення специфікації членами консультативного комітету є необхідною умовою успішного завершення розробки стандарту, він може надати специфікації статус запропонованої рекомендації, навіть якщо вона не одержала необхідної апробації.

Директор може зобов'язати робочу групу вирішити всі питання, підняті членами консультативного комітету при її розгляді, а також формально відповісти на зауваження, одержані від інших робочих груп і представників громадськості.

Після закінчення даного етапу директор може надати специфікації статус рекомендації, інакше він зобов'язаний "знизити" документ до кандидата до рекомендації або робочої версії.

Мабуть, лише перебування документа в цьому статусі вибивається із загальної тенденції, хоча було неправильно трактувати це неспівпадання як принципову відмінність – це, швидше за все, лише специфіка методики роботи консорціуму W3C.

Щоб запропонована рекомендація перетворилася на рекомендацію, директор повинен бути упевнений, що даний документ користується відчутною підтримкою з боку консультативного комітету, членів консорціуму, робочих груп W3C і громадськості. рішення про переказ документу статусу рекомендації (стандарту) є рішенням W3C.

Передбачається, що під час переходу специфікації в статус рекомендації члени консорціуму подають новій рекомендації усіляку підтримку (відстежують друкарські помилки, надають випробувальні програмні засоби і т. д.) і сприяють широкому застосуванню цього стандарту.

Отже W3C може публікувати і виправлені версії рекомендації, в яких указується, що було виправлено і які редакторські правки були внесені.