<?xml version="1.0" encoding="UTF-8"?>
<essay xml:lang="en" version="pto" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:gal="http://norman.walsh.name/rdf/gallery#">
<info>
    
    
    
    
    
    
    
    
    
<title>Son-of-RSS Grammar</title><biblioid class="uri">http://norman.walsh.name/2003/07/10/nechoGrammar</biblioid>
<volumenum>6</volumenum>
<issuenum>57</issuenum>
<pubdate>2003-07-10</pubdate>
<date>$Date: 2005-09-11 10:27:02 -0400 (Sun, 11 Sep 2005) $</date>
<author>
      <personname>
<firstname>Norman</firstname>
	<surname>Walsh</surname>
</personname>
    </author>
<copyright>
      <year>2003</year>
      <holder>Norman Walsh</holder>
    </copyright>
<abstract>
<para>Another RELAX NG Grammar for the format sometimes referred to
as Pie or Echo. And some more thoughts about Son-of-RSS.</para>
</abstract>
<dc:subject rdf:resource="http://norman.walsh.name/knows/taxonomy#Atom"/>
</info>

<para xml:id="p1">Yesterday,
<link xlink:href="/knows/who#tim-bray">Tim</link><indexterm>
      <primary>Bray</primary>
<secondary>Tim</secondary>
    </indexterm> asked me to take a look at the
RELAX NG grammar that he put together for
Pie/Not-Echo/Son-of-RSS. Before looking at his, I decided to followed the link to
Sam's<indexterm>
      <primary>Ruby</primary>
<secondary>Sam</secondary>
    </indexterm>
<link xlink:href="http://www.intertwingly.net/blog/1506.html">NECHO 0.1</link>
snapshot and take an independent crack at the problem.</para>

<para xml:id="p2">I think it's a good sign that
<link xlink:href="necho.rnc">my schema</link> and
<link xlink:href="http://www.tbray.org/ongoing/pie/0.1/pie.rnc">Tim's schema</link>
are similar. They differ a bit stylistically, but the technical discrepancies
are few (and perhaps consensus is leaning towards the choices Tim made; I haven't
been following the discussion in the past couple of weeks):</para>

<itemizedlist>
<listitem>
<para xml:id="p3">Tim made order insignificant in <tag>feed</tag> and
<tag>entry</tag>. I thought about doing that but
decided to impose one. It's marginally simpler to write applications
to consume the feed if the order is fixed and it doesn't seem a hardship on
authors in this case. And besides, allowing the feed title
to appear half way through a feed, between two entries, seems wrong.</para>
</listitem>

<listitem>
<para xml:id="p4">I decided to allow authors and contributors to have any number
of <tag>homepage</tag> and <tag>weblog</tag> elements.
(These are the sorts of decisions that need to be nailed down solidly
in the specification.)
</para>
</listitem>

<listitem>
<para xml:id="p5">On the subject of contributors, Tim named the pattern he used to define
the content model of <tag>author</tag> and <tag>contributor</tag>
<quote>Person</quote>. Are we really saying that organizational authorship is
forbidden? Suppose I want to point to a document authored by
<quote>Example, Inc.</quote>?
</para>
</listitem>

<listitem>
<para xml:id="p6">Tim imposed some additional constraints on the <tag>content</tag>
element that aren't justified by Sam's description or his example. (I'm going to
suggest some radical constraints below, so I don't think Tim's wrong, I just
took a more literal approach to the problem.)
</para>
</listitem>

<listitem>
<para xml:id="p7">I decided to allow <tag class="attribute">xml:lang</tag>
(and <tag class="attribute">xml:base</tag>) anywhere.
</para>
</listitem>

<listitem>
<para xml:id="p8">My grammar allows foreign-namespace content to be mixed into the
<tag>feed</tag> or the <tag>content</tag>.</para>
</listitem>

<listitem>
<para xml:id="p9">My grammar allows foreign-namespace attributes everywhere.</para>
</listitem>

<listitem>
<para xml:id="p10">Tim put some constraints on the version attribute and put the vocabulary
in a reasonable namespace. I didn't bother.</para>
</listitem>
</itemizedlist>

<para xml:id="p11">I haven't bothered to run my grammar through <application>Trang</application> to
produce the W3C XML Schemas and/or DTDs that might be desirable. Feel free.</para>

<section xml:id="whatswrong">
<title>What's Wrong with NECHO 0.1?</title>

<para xml:id="p12">Herewith, my two cents about what needs to change before 1.0. I think this
might classify as ranting again.</para>

<itemizedlist>
<listitem>
	<para xml:id="p13">Lose this nonsense about <quote>escaped</quote> content.
I'm <emphasis>serious</emphasis>. That is just <emphasis>broken</emphasis>!
Whether you use CDATA sections or numeric character references or named entities
<emphasis>is irrelevant</emphasis>. This is XML. You get a marked-up stream of
Unicode characters for gosh sakes!
</para>
      </listitem>

<listitem>
	<para xml:id="p14">Actually, lose <tag>content</tag> altogether.</para>

<para xml:id="p15">My first draft of this essay
had several bullets about how to improve content (allow only one, require XHTML,
don't allow content by reference), but I had a sort of epiphany when I realized
that entries had both <tag>summary</tag> and <tag>content</tag>.
</para>

<para xml:id="p16">Aha, I realized, the idea here must be that some folks want to stuff
the actual content into the feed instead of just pointing to it. (Perhaps I've
been spectacularly clueless in not realizing that sooner. Wouldn't be the first time.
Or the last.)</para>

<para xml:id="p17">I'm torn. I might be convinced that this is really a requirement, but not
easily.</para>

<para xml:id="p18">I don't think I've ever seen a feed that works this way, so I'm
inclined to say that if some folks really need it, they can do it in
an extension namespace. </para>
      </listitem>

<listitem>
	<para xml:id="p19">Rename <tag>summary</tag> to <tag>description</tag>.
Or not. This is a pretty minor point, but given that Dublin Core has established
the name <quote>description</quote>, why not use it?
</para>
</listitem>

<listitem>
	<para xml:id="p20">Allow text or XHTML (but nothing else) in
<tag>description</tag>.
</para>
</listitem>

<listitem>
	<para xml:id="p21">Put <tag>link</tag> inside <tag>author</tag> and lose
<tag>homepage</tag> and <tag>weblog</tag>. Trying to enumerate
the kinds of links people will want to associate with authors is futile.
<quote>There are only three numbers in computer science: zero, one, and infinity.</quote>
</para>
      </listitem>

<listitem>
	<para xml:id="p22">Lose <tag>subtitle</tag>s.
</para>
      </listitem>

<listitem>
	<para xml:id="p23">Add <tag>description</tag> and <tag>publisher</tag>
(with the same content model as author and contributor)
to <tag>feed</tag>.
</para>
      </listitem>

<listitem>
	<para xml:id="p24">I'm not sure the distinction between
<tag>author</tag> and <tag>contributor</tag> is worth
preserving. </para>
      </listitem>

<listitem>
	<para xml:id="p25">I'm not sure the distinction between
<tag>link</tag> and <tag>id</tag> is a good idea.
Maybe this is related to the idea that the feed would contain the
content, but since I don't think that should be standard, I don't
think both <tag>link</tag> and <tag>id</tag> need to
be standard. Lose <tag>id</tag>.
</para>
      </listitem>
</itemizedlist>

<para xml:id="p26">That's probably not an exhaustive list. And remember, my opinion is not
warranted to be worth more than what you paid for it.</para>

</section>

</essay>

