<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.oreilly.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0">
    <title>O'Reilly News: XML</title>
    <link rel="alternate" type="text/html" href="http://oreilly.com/xml/" />
    <id>tag:news.oreilly.com,2008-08-01://44</id>
    <updated>
</updated>
    <subtitle>XML news and articles from O'Reilly Media</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>



<atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/atom+xml" href="http://feeds.oreilly.com/oreilly/xml" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com" /><entry>
    <title>Japanese Standard for ODF</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/j_HtFD4WysU/japanese-standard-for-odf.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38663</id>

    <published>2009-12-08T06:54:38Z</published>
    <updated>2009-12-08T06:54:38Z</updated>

    <summary>Based on a cryptic twitter from Dr Murata,  it looks like the Japanese standard for ODF has been released.  Congratulations to all involved, it is a good step forward to enable competition, substitution and industry in this area. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="odf" label="odf" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        Based on a &lt;a href="http://twitter.com/muratamakoto/status/6424272274"&gt;cryptic twitter&lt;/a&gt; from Dr Murata,  it looks like the Japanese standard for ODF has been released.  Congratulations to all involved, it is a good step forward to enable competition, substitution and industry in this area. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/j_HtFD4WysU" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/12/japanese-standard-for-odf.html</feedburner:origLink></entry>

<entry>
    <title>Climategate and XML</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/5mt7NiY1R8g/climategate-and-xml.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38637</id>

    <published>2009-12-03T17:27:04Z</published>
    <updated>2009-12-03T17:27:04Z</updated>

    <summary>One interesting artifact to come out of the stolen Climategate material is an epic file HARRY_READ_ME.txt. It seems to be a year long log by a programmer (Harry?) who has to port old data and various old FORTRAN (and MATLAB?)...</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        One interesting artifact to come out of the stolen Climategate material is an epic file HARRY_READ_ME.txt. It seems to be a year long log by a programmer (Harry?) who has to port old data and various old FORTRAN (and MATLAB?)...
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/5mt7NiY1R8g" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/12/climategate-and-xml.html</feedburner:origLink></entry>


<entry>
    <title>Vale JCP?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/m0EDcEJ8AQg/vale-jcp.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38596</id>

    <published>2009-11-26T04:45:56Z</published>
    <updated>2009-11-26T04:45:56Z</updated>

    <summary>I am really impressed by Scala, though I have not used it on any real projects yet. Apart from reflection, it seems to be much stronger than Java in all the kinds of features that are good for XML document processing: co-routines, pattern matching and so on. The built-in XML tree that documents can be parsed in to does not contain back pointers, so up-going axes require extra coding; Scala is obviously more congenial for OmniMark or XSLT programmers than Java.</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="java" label="java" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="jcp" label="jcp" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="scala" label="scala" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        I am really impressed by Scala, though I have not used it on any real projects yet. Apart from reflection, it seems to be much stronger than Java in all the kinds of features that are good for XML document processing: co-routines, pattern matching and so on. The built-in XML tree that documents can be parsed in to does not contain back pointers, so up-going axes require extra coding; Scala is obviously more congenial for OmniMark or XSLT programmers than Java.
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/m0EDcEJ8AQg" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/vale-jcp.html</feedburner:origLink></entry>

<entry>
    <title>How far can documentation go?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/7BfxxUPb_ew/how-far-can-documentation-go.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38579</id>

    <published>2009-11-24T06:41:05Z</published>
    <updated>2009-11-24T06:41:05Z</updated>

    <summary>SAMBA's Jeremy Allison has a great post Why writing a Windows compatible file server is (still) hard.  What leaps out to me?  First, that the method of requiring complete documentation outside a formalized QA process doesn't work real well. The second thing is that even if there is documentation, some incompatibilities come down to capability mismatches.</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="standards" label="standards" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        SAMBA's &lt;a href="http://blog.coverity.com/posts/voices-of-scan-community/jeremy-allison-interview"&gt;Jeremy Allison&lt;/a&gt; has a great post &lt;a href="http://blogs.techrepublic.com.com/datacenter/?p=1341"&gt;Why writing a Windows compatible file server is (still) hard&lt;/a&gt;.  What leaps out to me?  First, that the method of requiring complete documentation outside a formalized QA process doesn't work real well. The second thing is that even if there is documentation, some incompatibilities come down to capability mismatches.
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/7BfxxUPb_ew" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/how-far-can-documentation-go.html</feedburner:origLink></entry>

<entry>
    <title>Schematron at the Associated Press</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/32qtY586Kro/schematron-at-the-associated-p.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38578</id>

    <published>2009-11-24T05:33:06Z</published>
    <updated>2009-11-24T05:33:06Z</updated>

    <summary><![CDATA[Stuart Myles has a quick slide presentation Schematron and Other Useful Tools at the IPTC Autumn Meeting  about how the Associated Press  reduced manual checking &amp; QA of incoming iAtom feeds using open source tools.]]></summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="schematron" label="schematron" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        Stuart Myles has a quick slide presentation &lt;a href="http://www.slideshare.net/smyles/schematron-and-other-useful-tools"&gt;Schematron and Other Useful Tools&lt;/a&gt; at the &lt;a href="http://www.iptc.org/ "&gt;IPTC&lt;/a&gt; Autumn Meeting  about how the Associated Press  reduced manual checking &amp;amp; QA of incoming iAtom feeds using open source tools.
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/32qtY586Kro" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/schematron-at-the-associated-p.html</feedburner:origLink></entry>

<entry>
    <title>How fuzzy should a date be?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/yLfdt32h_EA/how-fuzzy-should-a-date-be.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38570</id>

    <published>2009-11-23T05:54:32Z</published>
    <updated>2009-11-23T05:54:32Z</updated>

    <summary>From Bruce D'Arcus' Darcusblog comes a pointer on a U.S. Library of Congress initiative for a better date format Extended Date Time Format (EDTF). ISO 8601's problem is that almost anything is a date: if my memory serves me, some date values are ambiguous so you need to make a subset or add some attribute to say which kind of date you mean. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="dates" label="dates" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        From Bruce D'Arcus' &lt;a href="http://community.muohio.edu/blogs/darcusb/archives/2009/09/07/promoting-an-extended-date-time-format"&gt;Darcusblog&lt;/a&gt; comes a pointer on a U.S. Library of Congress initiative for a better date format &lt;a href="http://www.loc.gov/standards/datetime/index.html"&gt;Extended Date Time Format&lt;/a&gt; (EDTF). ISO 8601's problem is that almost anything is a date: if my memory serves me, some date values are ambiguous so you need to make a subset or add some attribute to say which kind of date you mean. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/yLfdt32h_EA" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/how-fuzzy-should-a-date-be.html</feedburner:origLink></entry>




<entry>
    <title>Leaked Draft of EU Interop Framework</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/T3gNYCCtjWE/leaked-draft-of-eu-interop-fra.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38471</id>

    <published>2009-11-11T08:02:24Z</published>
    <updated>2009-11-11T08:02:24Z</updated>

    <summary>Two months ago I alerted readers Europeans: only two weeks left to comment on ICT &amp; standards whitepaper. I am not sure on which dots actually join up, but a Dutch website has what is claimed to be a leaked late draft in English of European Interoperability Framework for European Public Services (EIF) Version 2.0. Here are some of the general recommendations related to standards and issues raised on this blog.</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="standards" label="standards" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        Two months ago I alerted readers &lt;a href="http://broadcast.oreilly.com/2009/08/europeans-only-two-weeks-left.html"&gt;Europeans: only two weeks left to comment on ICT &amp; standards whitepaper&lt;/a&gt;. I am not sure on which dots actually join up, but a Dutch website has what is claimed to be a leaked late draft in English of &lt;a href="http://blog.webwereld.nl/wp-content/uploads/2009/11/European-Interoperability-Framework-for-European-Public-Services-draft.pdf"&gt;European Interoperability Framework for European Public Services (EIF) Version 2.0&lt;/a&gt;. Here are some of the general recommendations related to standards and issues raised on this blog.
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/T3gNYCCtjWE" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/leaked-draft-of-eu-interop-fra.html</feedburner:origLink></entry>


<entry>
    <title>Announcing O'Reilly Answers</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/puiBWffkI30/announcing-oreilly-answers.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38407</id>

    <published>2009-11-04T14:30:00Z</published>
    <updated>2009-11-04T14:30:00Z</updated>

    <summary>We're launching the beta of O'Reilly Answers, and I'm inviting you to be part of it. In brief, O'Reilly Answers is a community site for sharing knowledge, asking questions, and providing answers that brings together our customers, authors, editors, conference speakers, and Foo (Friends of O'Reilly).  O'Reilly is at the center of an amazing exchange of knowledge sharing and idea generation, and we want you to join us in changing the world by spreading the knowledge of innovators.</summary>
    <author>
        <name>Allen Noren</name>
        <uri>http://radar.oreilly.com/allen/</uri>
    </author>
    
    <category term="actionscript" label="actionscript" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ajax" label="ajax" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="apache" label="apache" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="bsd" label="bsd" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="iphone" label="iphone" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="java" label="java" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="javascript" label="javascript" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="linux" label="linux" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="mac" label="mac" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="mysql" label="mysql" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="opensource" label="opensource" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="oracle" label="oracle" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="oscon" label="oscon" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="osx" label="osx" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="perl" label="perl" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="photoshop" label="photoshop" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="python" label="python" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="rails" label="rails" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ruby" label="ruby" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="unix" label="unix" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="web" label="web" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="web20" label="web20" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="windows" label="windows" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        We're launching the beta of &lt;a href="http://answers.oreilly.com"&gt;O'Reilly Answers&lt;/a&gt;, and I'm inviting you to be part of it. In brief, O'Reilly Answers is a community site for sharing knowledge, asking questions, and providing answers that brings together our customers, authors, editors, conference speakers, and Foo (Friends of O'Reilly).  O'Reilly is at the center of an amazing exchange of knowledge sharing and idea generation, and we want you to join us in changing the world by spreading the knowledge of innovators.
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/puiBWffkI30" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/11/announcing-oreilly-answers.html</feedburner:origLink></entry>

<entry>
    <title>Participation, participation, participation</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/agfdkyeccZI/participation-participation-pa.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38337</id>

    <published>2009-10-29T08:17:43Z</published>
    <updated>2009-10-29T08:17:43Z</updated>

    <summary>IBM marketing guy Rob Weir has half of a new series of blogs  The Final OOXML Update up. Readers may be surprised that I agree with many of the points he makes, among them, the importance of a balance of interests, the need for continued participation and the need for followthrough on the BRM decisions. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        IBM marketing guy Rob Weir has half of a new series of blogs  The Final OOXML Update up. Readers may be surprised that I agree with many of the points he makes, among them, the importance of a balance of interests, the need for continued participation and the need for followthrough on the BRM decisions. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/agfdkyeccZI" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/10/participation-participation-pa.html</feedburner:origLink></entry>


<entry>
    <title>The indexed XML website as a commodity</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/v2zFJsWByj8/the-indexed-xml-website-as-a-c.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38186</id>

    <published>2009-10-14T13:59:40Z</published>
    <updated>2009-10-14T13:59:40Z</updated>

    <summary>Reviewing a few long-term, continuing multi-publishing projects I have been involved in recently, I am struck that several are morphing in a particular direction. The projects might have started as publishing paper or webpages, and moved to publishing high-level XML, but increasingly the commodity that needs to be packaged and distributed (for re-skinning and re-use by third parties) is the whole indexed dataset: in effect the website (without the implication of HTML pages.)  The client-person doesn't GET a webpage, they get a whole website (this is for B2B not B2C.)</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        Reviewing a few long-term, continuing multi-publishing projects I have been involved in recently, I am struck that several are morphing in a particular direction. The projects might have started as publishing paper or webpages, and moved to publishing high-level XML, but increasingly the commodity that needs to be packaged and distributed (for re-skinning and re-use by third parties) is the whole indexed dataset: in effect the website (without the implication of HTML pages.)  The client-person doesn't GET a webpage, they get a whole website (this is for B2B not B2C.)
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/v2zFJsWByj8" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/10/the-indexed-xml-website-as-a-c.html</feedburner:origLink></entry>

<entry>
    <title>What are useful Software Engineering approaches for legislated requirements?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/cU2ILJZADmE/what-are-useful-software-engin.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38057</id>

    <published>2009-09-30T06:02:29Z</published>
    <updated>2009-09-30T06:02:29Z</updated>

    <summary>More projects seem to be coming across my desk that ultimately involve building information systems whose primary requirements come from legislation or regulations. And sometimes even the detailed requirements. Legislation is sometimes quite a nice Requirement Specification: it is expressed...</summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        More projects seem to be coming across my desk that ultimately involve building information systems whose primary requirements come from legislation or regulations. And sometimes even the detailed requirements. Legislation is sometimes quite a nice Requirement Specification: it is expressed...
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/cU2ILJZADmE" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/what-are-useful-software-engin.html</feedburner:origLink></entry>



<entry>
    <title>Linking a public government dataset into the semantic web with RDF</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/sKoQY6NzXWY/linking-a-public-government-da.html" />
    <id>tag:broadcast.oreilly.com,2009://53.38035</id>

    <published>2009-09-28T05:27:44Z</published>
    <updated>2009-09-28T05:27:44Z</updated>

    <summary>A few months ago, a client wanted to dip their toes in the semantic web. So I took a fresh look at the status quo, and where the current sweet spot is. Here are my conclusions, and how things panned out for this particular job. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="rdf" label="rdf" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        A few months ago, a client wanted to dip their toes in the semantic web. So I took a fresh look at the status quo, and where the current sweet spot is. Here are my conclusions, and how things panned out for this particular job. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/sKoQY6NzXWY" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/linking-a-public-government-da.html</feedburner:origLink></entry>


<entry>
    <title>Programming languages available in-house determines architecture?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/8DEWDQJmgtE/inhouse-programming-language-c.html" />
    <id>tag:broadcast.oreilly.com,2009://53.37993</id>

    <published>2009-09-22T15:07:11Z</published>
    <updated>2009-09-22T15:07:11Z</updated>

    <summary>A solid refactoring, the kind that you don't do every year, also needs to involve a tooling up, but scoped to making the new desired architecture something that programmers won't subvert but find natural. In a way, the programming languages become  the interfaces that  provides the boundaries for the layers of the system. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        A solid refactoring, the kind that you don't do every year, also needs to involve a tooling up, but scoped to making the new desired architecture something that programmers won't subvert but find natural. In a way, the programming languages become  the interfaces that  provides the boundaries for the layers of the system. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/8DEWDQJmgtE" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/inhouse-programming-language-c.html</feedburner:origLink></entry>


<entry>
    <title>The Grammar of Schematron</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/p8kZ3nnqkLE/the-grammar-of-schematron.html" />
    <id>tag:broadcast.oreilly.com,2009://53.37936</id>

    <published>2009-09-15T11:15:25Z</published>
    <updated>2009-09-15T11:15:25Z</updated>

    <summary>A lot of Schematron can be implemented directly in a mildly enhanced version of RELAX NG without (I think) explosions, before it all runs out of steam. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="relaxng" label="relax ng" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="schematron" label="schematron" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        A lot of Schematron can be implemented directly in a mildly enhanced version of RELAX NG without (I think) explosions, before it all runs out of steam. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/p8kZ3nnqkLE" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/the-grammar-of-schematron.html</feedburner:origLink></entry>

<entry>
    <title>XProc and SMIL: Orchestrating Pipelines</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/BcA6DpZaYNM/xproc-and-smil-orchestrating-p.html" />
    <id>tag:broadcast.oreilly.com,2009://53.36039</id>

    <published>2009-09-14T20:51:19Z</published>
    <updated>2009-09-14T20:51:19Z</updated>

    <summary>Although the W3C's XML Pipeline Language (XProc) hasn't even left the stable yet, people are already looking beyond its original purpose. XProc was designed to solve the problem of how to describe the joining together of multiple XML processing steps. So, the question is, how do you extend XProc to handle new features like explicit concurrency...</summary>
    <author>
        <name>Philip Fennell</name>
        
    </author>
    
    <category term="orchestration" label="orchestration" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="pipeline" label="pipeline" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="smil" label="smil" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xproc" label="xproc" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        Although the W3C's XML Pipeline Language (XProc) hasn't even left the stable yet, people are already looking beyond its original purpose. XProc was designed to solve the problem of how to describe the joining together of multiple XML processing steps. So, the question is, how do you extend XProc to handle new features like explicit concurrency...
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/BcA6DpZaYNM" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/xproc-and-smil-orchestrating-p.html</feedburner:origLink></entry>

<entry>
    <title>HTML 5 comics</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/RYR98Fpb2bk/html-5-comics.html" />
    <id>tag:broadcast.oreilly.com,2009://53.37928</id>

    <published>2009-09-11T10:06:47Z</published>
    <updated>2009-09-11T10:06:47Z</updated>

    <summary>CSS quirrel is an online comic that is good for a few laughs. You can tell it would be funny if you knew what on earth they all were talking about. Actually, most of the comics are really paired with blog items giving the back story. It is a really cute format. Read on for a few of my favorites. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="html5" label="html5" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        &lt;a href="http://www.cssquirrel.com/"&gt;CSS quirrel&lt;/a&gt; is an online comic that is good for a few laughs. You can tell it would be funny if you knew what on earth they all were talking about. Actually, most of the comics are really paired with blog items giving the back story. It is a really cute format. Read on for a few of my favorites. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/RYR98Fpb2bk" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/html-5-comics.html</feedburner:origLink></entry>


<entry>
    <title>Do we need lazy loading XML parsers to make XHTML scalable?</title>
    <link rel="alternate" type="text/html" href="http://feeds.oreilly.com/~r/oreilly/xml/~3/regbYmejdaQ/do-we-need-lazy-loading-xml-pa.html" />
    <id>tag:broadcast.oreilly.com,2009://53.37920</id>

    <published>2009-09-10T07:40:51Z</published>
    <updated>2009-09-10T07:40:51Z</updated>

    <summary>The W3C Systeam's blog has a hilarious item W3C's Excessive DTD Traffic. Apparently, generic XML systems are trying to download the DTD using the DOCTYPE declaration system identifier (i.e. what it is for) on XHTML files, or downloading the schemas from the namespace URI (i.e. not what it is for) for documents with XHTML fragments.  And it is a lot of bogus traffic. W3C does not want to cop having to serve dumb XHTML requests for DTDs and schemas. A different DOCTYPE and a lazy loading parser policy would help. But I think all the ISO/MathML special character public entity sets should be built into XML. </summary>
    <author>
        <name>Rick Jelliffe</name>
        
    </author>
    
    <category term="html" label="html" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="standards" label="standards" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xhtml" label="xhtml" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
        The W3C Systeam's blog has a hilarious item &lt;a href="http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic"&gt;W3C's Excessive DTD Traffic&lt;/a&gt;. Apparently, generic XML systems are trying to download the DTD using the DOCTYPE declaration system identifier (i.e. what it is for) on XHTML files, or downloading the schemas from the namespace URI (i.e. not what it is for) for documents with XHTML fragments.  And it is a lot of bogus traffic. W3C does not want to cop having to serve dumb XHTML requests for DTDs and schemas. A different DOCTYPE and a lazy loading parser policy would help. But I think all the ISO/MathML special character public entity sets should be built into XML. 
     &lt;img src="http://feeds.feedburner.com/~r/oreilly/xml/~4/regbYmejdaQ" height="1" width="1"/&gt;</content>
<feedburner:origLink>http://broadcast.oreilly.com/2009/09/do-we-need-lazy-loading-xml-pa.html</feedburner:origLink></entry>

</feed>
