<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Rick Jelliffe on O&apos;Reilly Broadcast</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/" />
<link rel="self" type="application/atom+xml" href="http://broadcast.oreilly.com/atom.xml" />
<id>tag:broadcast.oreilly.com,2008-08-07://53</id>
<updated>2009-11-06T04:45:46Z</updated>

<generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>

<entry>
<title>Tactical and strategic XML design</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/11/tactical-and-strategic-xml-des.html" />
<id>tag:broadcast.oreilly.com,2009://53.38436</id>

<published>2009-11-06T03:35:58Z</published>
<updated>2009-11-06T04:45:46Z</updated>

<summary>So I guess when we look at a system&apos;s architecture, the first thing we can do is ask &apos;Is this XML here being used strategically or tactically?&apos;  A strategic use might be, for example, to allow long-term archiving; a tactical use might be XML in AJAX (where using JSON would be another tactic.)  If the answer is tactical, then we can ask &apos;Is it implemented in a way that allows flexible rearrangement, when a different tactic becomes appropriate?&apos;   </summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="architecture" label="architecture" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="design" label="design" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="xml" label="xml" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="xslt" label="xslt" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
So I guess when we look at a system&apos;s architecture, the first thing we can do is ask &apos;Is this XML here being used strategically or tactically?&apos;  A strategic use might be, for example, to allow long-term archiving; a tactical use might be XML in AJAX (where using JSON would be another tactic.)  If the answer is tactical, then we can ask &apos;Is it implemented in a way that allows flexible rearrangement, when a different tactic becomes appropriate?&apos;   
</content>
</entry>

<entry>
<title>Participation, participation, participation</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/10/participation-participation-pa.html" />
<id>tag:broadcast.oreilly.com,2009://53.38337</id>

<published>2009-10-29T08:17:43Z</published>
<updated>2009-10-29T19:54:54Z</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. 
</content>
</entry>

<entry>
<title>The indexed XML website as a commodity</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/10/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-15T13:58:38Z</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&apos;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&apos;t GET a webpage, they get a whole website (this is for B2B not B2C.)
</content>
</entry>

<entry>
<title>What are useful Software Engineering approaches for legislated requirements?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/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-30T15:38:31Z</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...
</content>
</entry>

<entry>
<title>Now I have seen everything!</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/now-i-have-seen-everything.html" />
<id>tag:broadcast.oreilly.com,2009://53.38056</id>

<published>2009-09-30T05:01:43Z</published>
<updated>2009-09-30T05:35:33Z</updated>

<summary>I have always thought the context-senstive { a^n, b^n, c^n: n &gt;=1} s was a kind of theoretical construct that you would never see in a real-life XML document.  Today, I have actually seen one!</summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="schema" label="schema" 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 have always thought the context-senstive { a^n, b^n, c^n: n &gt;=1} s was a kind of theoretical construct that you would never see in a real-life XML document.  Today, I have actually seen one!
</content>
</entry>

<entry>
<title>Linking a public government dataset into the semantic web with RDF</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/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-29T05:00:50Z</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. 
</content>
</entry>

<entry>
<title>The Norwegians still get it!</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/the-norwegians-still-get-it.html" />
<id>tag:broadcast.oreilly.com,2009://53.38034</id>

<published>2009-09-28T00:53:50Z</published>
<updated>2009-09-28T02:31:58Z</updated>

<summary>These all seem the right way to do things: a user decides what it needs for specific uses, is pragmatic or generous about timing, and doesn&apos;t exclude any of the technical eco-systems from equal participation. I think it also represents a real challenge to the software vendors: starting 2011 they will have to compete on features, quality and support, not file format: they won&apos;t have the supposed lock-in to benefit or excuse them from providing value. </summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="odf" label="odf" scheme="http://www.sixapart.com/ns/types#tag" />
<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/">
These all seem the right way to do things: a user decides what it needs for specific uses, is pragmatic or generous about timing, and doesn&apos;t exclude any of the technical eco-systems from equal participation. I think it also represents a real challenge to the software vendors: starting 2011 they will have to compete on features, quality and support, not file format: they won&apos;t have the supposed lock-in to benefit or excuse them from providing value. 
</content>
</entry>

<entry>
<title>Programming languages available in-house determines architecture?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/inhouse-programming-language-c.html" />
<id>tag:broadcast.oreilly.com,2009://53.37993</id>

<published>2009-09-22T15:07:11Z</published>
<updated>2009-09-23T02:33:51Z</updated>

<summary>A solid refactoring, the kind that you don&apos;t do every year, also needs to involve a tooling up, but scoped to making the new desired architecture something that programmers won&apos;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&apos;t do every year, also needs to involve a tooling up, but scoped to making the new desired architecture something that programmers won&apos;t subvert but find natural. In a way, the programming languages become  the interfaces that  provides the boundaries for the layers of the system. 
</content>
</entry>

<entry>
<title>W3C Widgets: Yet another XML-in-ZIP file format?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/w3c-widgets-yet-another-xml-in.html" />
<id>tag:broadcast.oreilly.com,2009://53.37983</id>

<published>2009-09-21T03:37:53Z</published>
<updated>2009-09-21T12:11:58Z</updated>

<summary>It will be interesting to see how big a widget can get: can it be a full word processor? And what makes widget so different from applets?</summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="html" label="html" 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/">
It will be interesting to see how big a widget can get: can it be a full word processor? And what makes widget so different from applets?
</content>
</entry>

<entry>
<title>Beware of browser and OS numbers</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/beware-of-browser-and-os-numbe.html" />
<id>tag:broadcast.oreilly.com,2009://53.37962</id>

<published>2009-09-17T05:45:37Z</published>
<updated>2009-09-17T07:35:44Z</updated>

<summary>For some markets the success/domination by Microsoft is much stronger than blanket figures indicate.</summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="html" label="html" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
For some markets the success/domination by Microsoft is much stronger than blanket figures indicate.
</content>
</entry>

<entry>
<title>The Grammar of Schematron</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/the-grammar-of-schematron.html" />
<id>tag:broadcast.oreilly.com,2009://53.37936</id>

<published>2009-09-15T11:15:25Z</published>
<updated>2009-09-16T14:51:16Z</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. 
</content>
</entry>

<entry>
<title>HTML 5 comics</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/html-5-comics.html" />
<id>tag:broadcast.oreilly.com,2009://53.37928</id>

<published>2009-09-11T10:06:47Z</published>
<updated>2009-09-11T14:51:10Z</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/">
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. 
</content>
</entry>

<entry>
<title>Draft HTML 5: no longer a markup language but a machine?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/draft-html-5-no-longer-a-marku.html" />
<id>tag:broadcast.oreilly.com,2009://53.37922</id>

<published>2009-09-10T13:10:26Z</published>
<updated>2009-09-14T08:51:43Z</updated>

<summary>But seriously, what is the point of keeping this kind of rubbish? </summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="html" label="html" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="html5" label="html5" scheme="http://www.sixapart.com/ns/types#tag" />
<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/">
But seriously, what is the point of keeping this kind of rubbish? 
</content>
</entry>

<entry>
<title>Do we need lazy loading XML parsers to make XHTML scalable?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/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-10T15:19:04Z</updated>

<summary>The W3C Systeam&apos;s blog has a hilarious item W3C&apos;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&apos;s blog has a hilarious item W3C&apos;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. 
</content>
</entry>

<entry>
<title>Jotting on parsers for SGML-family document languages: SGML, HTML, XML #5</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/jotting-on-parsers-for-sgml-fa-3.html" />
<id>tag:broadcast.oreilly.com,2009://53.37917</id>

<published>2009-09-10T04:47:56Z</published>
<updated>2009-09-10T08:54:31Z</updated>

<summary>Collapsing bubbles. Converting a DTD with tag omission to a regular grammar. Needing the stack for less.  Term rewriting. On the fly addition of rules. Are SGML-family documents trees?  SGML as a centre of gravity no more?</summary>
<author>
<name>Rick Jelliffe</name>

</author>

<category term="html" label="html" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="parser" label="parser" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="sgml" label="sgml" 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/">
Collapsing bubbles. Converting a DTD with tag omission to a regular grammar. Needing the stack for less.  Term rewriting. On the fly addition of rules. Are SGML-family documents trees?  SGML as a centre of gravity no more?
</content>
</entry>

</feed> 