[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [syndication] Re: Thoughts, questions, and issues.
I'm cross-posting to rss-dev. It would be great if this thread
continued there, but there may not be good intersection at the
moment...
Eric Bohlman wrote:
>
> On Thu, 17 Aug 2000 malexander@acm.org wrote:
>
> > RSS 1.0 has lost it. Plain and simple. The new tag allows the spec
> > to kind of almost have it for a single level of depth. But the
> > idea of specific link tags to define a level of hierarchy will
> > simply fail when the data has multiple levels of Hierarchy.
> > The data I am looking at has about 8 levels of Hierarchy.
> > It can easily be encoded in RSS 0.91, but will fail completely
> > with RSS 1.0.
> >
> > If this tag structure is required to support RDF, then maybe the
> > RDF support should be re-considered. I dont have any issues with
>
> It's required, AFAIK, to simultaneously support RDF and be
> backwards-compatible with RSS 0.90.
The inchannel and item tags are _only_ used to thread together the
pre-existing RSS09 structures. You can add additional hierarchical
structures in extension modules using either familiar XML approaches,
RDF approaches, or a combination of both. An example is the proposed
content module [1] that Aaron Swartz was written up (and kindly added
me as a co-author based on some comments I made on his proposal [2]).
Another similar example is used in the taxonomy module [3].
The example in the content proposal (see below) shows how multiple
representations (XHMTML, HTML, Text, etc..) of the content of an item
could be described. The descriptive portion of the content module has
three levels of nesting. The actual contents can have as much nesting
as you want.
Since the content itself is very unlikely to be RDF, you use one of
several ways to escape it. The primary way to escape XML content that
isn't RDF (but should still be processed as XML) is to use the escape
attribute rdf:parseType="Literal" on the containing element. This
indicates that the contents of the element are well-formed XML but
shouldn't be interpreted as RDF. The first content in the example
below uses this approach to escape the embedded XHTML.
<item>
<content:content>
<rdf:Description>
<content:format>xhtml</content:format>
<rdf:value rdf:parseType="Literal">
This is a demonstration of <strong>XHTML</strong> in
RSS!
</rdf:value>
</rdf:Description>
</content:content>
<content:content>
<rdf:Description>
<content:format>html</content:format>
<rdf:value> <!-- don't need to escape since its just
text -->
<![CDATA[
This is a demonstration of <b>HTML</b> in RSS!
]]>
</rdf:value>
</rdf:Description>
</content:content>
<content:content>
<rdf:Description>
<content:format>text</content:format>
<rdf:value>This is a demonstration of **plain text** in
RSS!</rdf:value>
</rdf:Description>
</content:content>
<item>
You can use this RDF escape on any extension element including
top-level elements in which case all of your extension could be
RDF-free. You would be giving up on the structuring and reference
mechanisms of RDF and the ability to intermix other descriptive
vocabularies like dublin core, but that's your choice to make. The
small amount of syntax that the current proposal asks of you is to add
the rdf:parseType="Literal" escape attribute to the relavent elements
in your module.
You could even combine this with a default namespace and end up with
an element subtree that didn't visibly have namespaces or RDF. In
fact, you could do that to your entire module by putting it into one
top-level element that had something like:
<item>
<mywhizzytagset rdf:parseType="Literal"
xmlns="http://ihatenamespacesandrdf">
<awhizzysubtag>
<awhizzysubsubtag/>
</awhizzysubtag>
</mywhizzytagset>
</item>
You can also use the common way of escaping XML content in another XML
document by using CDATA sections (as the second content example above
uses). In this case, since the contents are just text and don't
contain markup, you don't need to use an rdf escape. You can even do
character level escaping of the embedded XML like I seem to remember a
version of the UserLand XML outline format uses in some places. Again,
this would just be a string as far as an RSS1 processor is concerned
and wouldn't need to be escaped.
Hope this helps,
Gabe
[1] http://www.egroups.com/files/rss-dev/Modules/Proposed/content.html
[2] http://www.egroups.com/message/rss-dev/16
[2] http://www.egroups.com/files/rss-dev/modules.html#s3.4
--
---------------------------
http://www.jfinity.com/gabe