• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
  • XML 問題: 管道流微格式

    發表于:2007-05-25來源:作者:點擊數: 標簽:
    計算中最優雅的抽象之一就是 UNIX 中的管道結構。管道允許通過把一個程序的輸出作為另一個程序的輸入而將一些小程序連接起來以實現重用,這些小程序只能做一件事,但是能做得很好。不幸的是,因此大部分 UNIX 管道是面向行處理的,不能直接用于 XML 處理。我
    計算中最優雅的抽象之一就是 UNIX® 中的管道結構。管道允許通過把一個程序的輸出作為另一個程序的輸入而將一些小程序連接起來以實現重用,這些小程序只能做一件事,但是能做得很好。不幸的是,因此大部分 UNIX 管道是面向行處理的,不能直接用于 XML 處理。我們將考察一些現有的工具,這些工具是致力于解決該問題的很多嘗試的成果。

    流是一個與管道有關的概念:即管道操作的對象。流的思想是程序不需要等待所有的數據都就緒后才開始工作,這樣程序就可以處理隨時生成的數據、在網絡上傳輸的數據或者不能全部裝載到內存中的大文件。

    (注意:下面的段落中將提到很多工具、規范和庫。在本文最后的 參考資料 部分可以找到相關鏈接。)

    為何要使用管道流?

    管道和流技術在 UNIX 上取得了極大成功,在很多其他系統上的應用也獲得了不同程度的成功。在多數編程語言和操作系統上能以這種或那種形式使用。在 XML 中,最常見的管道和流處理形式是 SAX Filter。本專欄的多數讀者都知道,SAX 表示 Simple API for XML。這是一種基于流的 API,解析 XML 并在解析過程中發生重大事件時(比如打開或關閉元素)調用事件處理程序。因為 SAX 處理不需要維護狀態或者構造龐大的數據結構(比如 DOM),通常用于操作大型數據集(很難全部裝載到內存中)、需要快速處理或者稀疏處理(只選擇部分 XML 使用而忽略其他部分)的 XML 任務。

    在編程語言層(比如 Java™ InputStreamReader 類或者 SAX Filter)使用管道和過濾器的問題在于,必須在最底層工作,需要編寫單調的、易出錯的和重復性的代碼。為了提升代碼的抽象層次,同時要保持足夠的靈活性以適應各種 XML 處理任務,人們開發了下面要討論的不同庫和工具。此外,將幾種 XML 工具連接起來進行分階段處理(管道)很多時候需要多次重復解析 XML。從一個階段轉到另一個階段時最好將處理后的 XML 保存在內存中。

    但首先我們來看看使用管道流處理庫能夠解決什么問題,既然用這種抽象方法處理 XML 非常好,到底能用來做什么呢?

    XML 管道的一些常見用途包括:

    • 讀取/解析 XML(無論在磁盤上、網絡上、XMS 中或者其他地方)
    • 將非 XML 轉化成 XML(比如將 reStructured Text 轉化成 XHTML)
    • 驗證(不論使用 DTD、XSchema、RelaxNG 還是 Schematron)
    • 組合 XML 片段(比如通過 XInclude 或 DITA Maps)
    • 轉換(可能使用 XSLT)
    • 填充模板(用實際內容代替占位符)
    • 格式化以便顯示或打?。ㄍㄟ^ CSS 或 XSL-FO)
    • 序列化/寫回 XML(磁盤、網絡、CMS 或其他地方)
    • 用聲明性語法將這些連在一起(通常也使用 XML)

    注意,一個管道可能包含全部這些應用或者其中的任何一些,有的可能還要重復或者有所變化,也可能包含其他定制的成分。但這些似乎是 XML 處理的核心內容。并且像前面所述的那樣,整個處理過程中管道應該保留解析后的 XML,而不需要在每個階段反復解析。

    比方說,可以用表示人和事件的零散標記組裝成 Web 日程表。也可以反其道而行,通過掃描幾個人的 Web 日程表將他們的安排收集起來確定適當的會議時間。本文將使用日程表和人員作為例子,但這種思路適合于任何能夠用 XML 表達的東西(現在真是太多了)。





    回頁首


    微格式運動

    選擇日程表作為例子的原因之一是現在興起了一種 “微格式” 運動,即用現有的 XML 方言表示原來的規范,而不是重新發明輪子或者別的東西。它們關注的最常見的 XML 方言是 XHTML,使用 classlink 屬性來增加人類可讀(在網頁中)和機器可讀(通過在屬性中包含針對機器的數據)的語義。這類微格式包括關于個人和組織的(基于 vCard 規范的 hCard)、日程表和事件(基于 iCalendar 規范的 hCalendar)、大綱和鏈接(XOXO)、標記和關鍵字(rel-tag)、審閱(hReview)、社會網絡(XFN)、內容許可(rel-license)等等。本文主要討論 hCalendar。

    清單 1 顯示了 hCalendar 微格式的一個例子:


    清單 1. hCalendar 微格式
    <div class="vevent">
                <abbr class="dtstart" title="20060322T0830-0800">
                March 22, 2006 - 08:30
                </abbr> -
                <abbr class="dtend" title="20060322T0900-0800">
                09:00
                </abbr> -
                <span class="summary">
                Dentist Appointment
                </span> - at
                <span class="location">
                Office on Pacific Ave.
                </span>
                <div class="description">
                Get permanent crown installed.
                </div>
                </div>

    該例是用 hCalendar 創建程序生成的。Phil Dawes 在網站上提供了一個解析 hCalendar 和 hCard 的 python 庫,在 hCalendar 頁面上還可以找到更多工具和實現。使用 Greasemonkey 擴展的Firefox® 用戶甚至能夠找到從所訪問的頁面抽取各種微格式的 Greasemonkey 腳本。Upcoming.org 和 Eventful.com 在網站上用 hCalendar 格式提供事件和日程表。顯然我們能找到大量使用微格式的數據來處理。





    回頁首


    再回到管道和流

    找到或者創建 XML 數據后如何建立一個管道來處理它呢?有多種方法,復雜程度各不相同。SAX Filters 作為一種底層的管道類型,常常被用作其他工具箱的基礎或者靈感的來源。XMLGAWK 擴展了面向行的編程語言 GNU AWK,為了處理 XML,它不再面向行而改為面向元素。XmlRpcFilteringPipe 是 Lion Kimbro 開發的管道流工具,使用 XML-RPC 創建管道。NetKernel™ 是作為整套工具箱出現的,它采用了管道流的概念并將其推到極致。Apache Cocoon 是圍繞著 “組件流” 這個概念建立的,在概念上和 XML 管道流類似,但是更加復雜。所有這些技術都提供了很好的方法,但是我想討論兩種在能力和簡單性之間取得最佳平衡(對我而言)的項目,然后介紹幾種有前途的開發項目。

    首先是來自 Sean McGrath 的 XPipe。Sean 還開發了 Pyxie(現在到了 Pixie2),它將 XML 轉化成適合于標準 UNIX 管道和過濾器處理的面向行的語言。此外,XPipe 開提供一組可擴展的 Java 組件。我認為 Sean 走對路了,但現在計劃似乎失敗了。網站有段時間沒有更新了,Sean 在郵件中告訴我他的公司有一個商業版本需要繼續開發,因此沒有時間再作開放源代碼的版本,如果再做的話會有很大的變化。我認為他采取了一種很好的方法,但我認為在保留基本思路的同時還可以更簡單一點。

    目前我看到的最有競爭力的是 Norm Walsh 的 Simple XML Pipeline(或者叫做 SXPipe)。它基本上包括本文開始列出的所有 XML 處理任務(這不是偶然的,這個列表就是以 SXPipe 的功能為基礎的),具有良好的規范,很容易為其編寫 XML。但有一些要求:它默認需要 Java 1.5,目前在 OS X 上只能得到開發人員預覽版,而且這些階段本身都是龐大的 Java 組件,使得系統擴展起來不像預期的那樣容易,但與 SXPipe 所實現的功能相比這都是些小問題。除了簡單的語法和處理模型外,SXPipe 本身非常簡單(只有五個元素)并且是基于標準的(利用了 XPath 1.0、XML Namespaces、XML Base和 XSL Transformation,在適當的上下文中使用這些規范)。這種語言甚至比 W3C 注解(Norm 參與編輯)“XML Pipeline Definition Language” 更簡單,但又保留了早期可以工作的基本能力和靈活性。清單 2 展示了一個 SXPipe 文檔例子:


    清單 2. SXPipe 文檔
    <pipeline xmlns="http://sxpipe.dev.java.net/xmlns/sxpipe/">
                <stage process="Read" input="dw-article.xml"/>
                <stage process="Validate" schema="dw-article-5.0.xsd"/>
                <stage process="Transform" stylesheet="dw-article-5.0.xsl"/>
                <stage process="Write" output="dw-article.html"/>
                </pipeline>

    既簡單又可愛。我的設想是能夠用 Python 進行擴展。比方說,我可以很方便地增加將 Restructured Text 處理為 XML 的階段作為管道的一部分,或者應用 Cheetah 模板。用 Python 實現 SXPipe 不會非常困難,但是要實現可移植性有些挑戰,因為 Python 沒有默認提供 XSL 或 XML 驗證庫。

    管道流的前途是光明的。因為出于同樣的目的出現了如此多的工具,這似乎表明確實存在對管道流的需要。無論最終以 SXPipe(比方說)作為標準,還是繼續沿著自己的道路滾滾向前,管道和流仍將存在。從我喜愛的編程語言 Python 的角度來看,PullDom 已經作為標準庫的一部分存在好幾年了,并將在 Fredrik Lundh 的 ElementTree 庫 2.5 版中進一步加強。我曾經試圖使用 ElementTree 實現 SXPipe,但是它仍然沒有轉換或驗證工具,對 XPath 的支持也很有限。Martijn Faassen 的 lxml 庫用 Python 封裝了功能強大,但難以使用的 libxml2 和 libxslt,公開了和 ElementTree 一樣簡單的接口以及 XInclude、完整的 XPath、XSLT 和各種形式的驗證。如果該項目穩定下來,用 Python 創建較好的 SXPipe 實現就比較容易了。





    回頁首


    結合在一起

    現在已經有了一些微格式內容和建立管道的工具,接下來該做什么呢?我們來探討幾種可能性。這僅僅是一種思維實驗,因此 URL 只作為例子并不真正指向什么地方。假設您是基本的家庭四口之家的一分子:Wanda(母親)、Xathrus(父親)、Yolanda(女兒)和 Zander(兒子)。每個人在自己的網頁上都有一個日程安排表,格式為 http://example.com/calendar/[name]/[period],其中 period 可以是年、年-月、年-月-日或者某個自然語言短語,如 “tomorrow” 或 “next week”?,F在需要定期地收集這些安排來導入 Apple® 的 iCal® 或 Mozilla® 的 Sunbird™ 這類程序。從 Web 上下載一個 XSLT 轉換樣式表把 hCalendar 轉化成 iCalendar,稱之為 “cal-transform.xsl”,然后使用 清單 3 中的源文檔(source-calendar.xml):


    清單 3. source-calendar.xml
                <calendar xmlns:xi="http://www.w3.org/2001/XInclude">
                <xi:include href="http://example.com/calendar/Wanda/today"/>
                <xi:include href="http://example.com/calendar/Xathrus/today"/>
                <xi:include href="http://example.com/calendar/Yolanda/today"/>
                <xi:include href="http://example.com/calendar/Zander/today"/>
                </calendar>
                

    然后將管道 清單 4 應用于源文檔:


    清單 4. 添加到源文檔
                <pipeline xmlns="http://sxpipe.dev.java.net/xmlns/sxpipe/">
                <stage process="Read" input="source-calendar.xml"/>
                <stage process="XInclude"/>
                <stage process="Transform" stylesheet="cal-transform.xsl"/>
                <stage process="Write" systemId="family-calendar.ics"/>
                </pipeline>
                

    完成這些之后運行管道將得到可導入的單個日程表文件。我們來看看不同的用例。如果微格式推廣開,應該能夠從銀行(帳戶和信用證明)、雜貨店(數字格式的收據)、甚至圖書館下載自己的數據。即使不關心其中大部分數據是否有效,但是仍然希望用模式驗證銀行數據。所有的數據源都希望轉換數據以統一到一種格式。因此要發揮您的想像力(暫不考慮安全問題,畢竟這里討論的是管道流)將這些不同的資源集中到一個流中,如 清單 5 所示:


    清單 5. 單一流
                <pipeline xmlns="http://sxpipe.dev.java.net/xmlns/sxpipe/">
                <!-- Get my schedule for the day -->
                <stage process="Read" input="http://myjob.com/myappointments"/>
                <stage process="Transform" stylesheet="calendar-to-portal.xsl"/>
                <stage process="Write" systemId="work.xml"/>
                <!-- Do I have any books due back at the library? -->
                <stage process="Read" input="http://muni-library.gov/books-due"/>
                <stage process="Transform" stylesheet="library-to-portal.xsl"/>
                <stage process="Write" systemId="library.xml"/>
                <!-- Get latest transactions in my chequing account -->
                <stage process="Read" input="http://mybank.com/chequeing-acct"/>
                <stage process="Validate" schema="my-bank-acct.xsd"/>
                <stage process="Transform" stylesheet="chequing-to-portal.xsl"/>
                <stage process="Write" systemId="chequeing.xml"/>
                <!-- Get latest transactions on my credit card -->
                <stage process="Read" input="http://mybank.com/my-credit-acct"/>
                <stage process="Validate" schema="my-creditcard.xsd"/>
                <stage process="Transform" schema="creditcard-to-portal.xsl"/>
                <stage process="Write" systemId="creditcard.xml"/>
                <!-- Check the weather forecast -->
                <stage process="Read" input="http://localweather.com"/>
                <stage process="Transform" stylesheet="weather-to-portal.xsl"/>
                <stage process="Write" systemId="weather.xml"/>
                <!-- Create an XInclude document to glue it all together -->
                <stage process="Document" label="accumulator">
                <portal xmlns:xi="http://www.w3.org/2001/XInclude"
                xmlns:"http://www.example.com/portal">
                <xi:include href="work.xml"/>
                <xi:include href="library.xml"/>
                <xi:include href="chequeing.xml"/>
                <xi:include href="creditcard.xml"/>
                <xi:include href="weather.xml"/>
                </portal>
                </stage>
                <stage process="XInclude"/>
                <!-- Convert it all to HTML -->
                <stage process="Transform" stylesheet="portal-to-html.xsl"/>
                <!-- Viola! We have our own personal portal on the world -->
                <stage process="Write" systemId="my-daily-portal.html"/>
                </pipeline>
                







    結束語

    我看到似乎有人對最后一個例子有點懷疑,這是因為我還沒有說明微格式和聯合的結合點。大量當前的微格式內容被設計來(或者花樣翻新為)流入新聞提要聚合程序,后者最初用于讀取 RSS 格式的博客。流入聚合程序的不僅僅有 hCalendar,正如前一個例子中所提示的:已經出現了用于審閱和大綱、事件和人員的微格式,但是很快就會看到用于商業交易、過期圖書、天氣預報以及無法預料的其他事物的微格式。

    除了微格式外,新出現的另一股力量是 Atom,它實際上是兩種不同的規范,即 Atom 聯合格式和 Atom API。與 Atom 的聯合非常類似于與原來的 RSS 格式的聯合,但是規范更明確(它是一個 IETF 標準)。不過這是下一期文章要討論的內容了,我將探討微格式和 Atom 聯合的結合點。到時候,您的管道也許已經沒有漏洞,流也干凈了。

    原文轉自:http://www.kjueaiud.com

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>