Edd Dumbill wrote:
>
> On Tue, Aug 15, 2000 at 02:46:28PM -0500, Aaron Swartz wrote:
> > David King <david.king@...> wrote:
> >
> > > When a date is needed anywhere in RSS 1.0, I would urge that a format
> > > such as the one in RFC 822 _not_ be used...
> > > ...The easiest date format I've worked with by far is the UNIX timestamp
> > > (the number of seconds since the Unix Epoch - January 1 1970 00:00:00
> > > GMT).
> >
> > UNIX timestamp is fine with me, it's the standard format for the language I
> > use (Tcl). I only suggested RFC 822 for consistency, but you bring up a good
> > point. The only thing is that UNIX timestamp isn't much of a standard, and
> > will cause problems when it overflows the integer (~2036, IIRC), but that
> > isn't much of a deal for me. Anyone else have concerns?

I'm assuming we will have 64-bit ints by then so overflowing would be a
non-issue (right?).  A good point to bring up none-the-less.

>
> http://www.uic.edu/year2000/datefmt.html
>
> ISO 8601 is the right format for dates

The reason I proposed using a UNIX timestamp is so the developer has a
trivial job of displaying the date in any format they feel their
audience would want.  ISO 8601's format would still need to be parsed to
get the individual parts of the date.  As I looked through the website
you posted, I noticed that it had a section on how to use ISO 8601 in
programs.  I snipped the PERL version:

<snip>
Perl Programs

Perl's built-in function time returns the number of seconds since
Midnight, January 1, 1970, GMT. It's conversion
functions gmttime, localtime will convert such a quantity to date and
time quantities.

To write this time stamp to a file in ISO format:

(under construction)
</snip>

I've been in the computer biz for a little more than a year now, and the
formatting of dates confuses and annoys me constantly.  Hopefully
somebody can answer this:  If the UNIX timestamp is the base time format
(i.e. string formats are built from it), then why isn't it used to store
dates?  Why are formats such as ISO 8601 used?  Any string format of a
date would need to be reformatted by a programmer if they wanted to use
a different date format.

Since RSS would be used by a world that represents dates in a multitude
of different formats, wouldn't we want to store the date in a way that
_any_ programmer could easily use no matter what format they are
familiar with?

-David

Hi,

Just fiddling a bit with some more tools :-)

I uploaded a DTML Method file[1] for the Zope-based[2] Squishdot[3]
discussion forum product.  The method produces an outgoing RSS feed
compliant with the core of http://purl.org/rss/1.0/.

I'll be updating it soon with a more interesting version supporting
categories, etc.

Enjoy!

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------

[1] http://www.egroups.com/files/rss-dev/Tools/squishdot_rss10%2Etxt
[2] http://www.zope.com
[3] http://www.squishdot.org

On Tue, 15 Aug 2000, Edd Dumbill wrote:

>
> On Tue, Aug 15, 2000 at 02:46:28PM -0500, Aaron Swartz wrote:
> > David King <david.king@...> wrote:
> >
> > > When a date is needed anywhere in RSS 1.0, I would urge that a format
> > > such as the one in RFC 822 _not_ be used...
> > > ...The easiest date format I've worked with by far is the UNIX timestamp
> > > (the number of seconds since the Unix Epoch - January 1 1970 00:00:00
> > > GMT).
> >
> > UNIX timestamp is fine with me, it's the standard format for the language I
> > use (Tcl). I only suggested RFC 822 for consistency, but you bring up a good
> > point. The only thing is that UNIX timestamp isn't much of a standard, and
> > will cause problems when it overflows the integer (~2036, IIRC), but that
> > isn't much of a deal for me. Anyone else have concerns?
>
> http://www.uic.edu/year2000/datefmt.html
>
> ISO 8601 is the right format for dates

There's a W3C Note describing a profile of 8601 which might be a good
fit for us here.

	 http://www.w3.org/TR/NOTE-datetime


	 Abstract
	 This document defines a profile of ISO 8601, the International Standard
	 for the representation of dates and times. ISO 8601 describes a large
	 number of date/time formats. To reduce the scope for error and the
	 complexity of software, it is useful to restrict the supported formats
	 to a small number. This profile defines a few date/time formats, likely
	 to satisfy most requirements.


From the introduction:

	 ISO 8601 describes a large number of date/time formats. For example it
	 defines Basic Format, without punctuation, and Extended Format, with
	 punctuation, and it allows elements to be omitted. This profile defines
	 a restricted range of formats, all of which are valid ISO 8601 dates and
	 times. The aim is to simplify the use of ISO 8601 in World Wide
	 Web-related standards, and to avoid the need for the developers and
	 users of these standards to obtain copies of ISO 8601 itself.

[...]

	 This profile may be adopted by standards which require an unambiguous
	 representation of dates and times. As different standards have their own
	 requirements regarding granularity and flexibility, this profile offers
	 a number of options. An adopting standard must specify which of these
	 options it permits.



Hmm... a profile of a profile of a profile; guess the original must be
pretty hairy!


For reference, the (unqualified) Dublin Core 1.1 spec adopts this
profile of 8601:

http://purl.org/dc/documents/rec-dces-19990702.htm
	 Element: Date
	   Name:        Date
	   Identifier:  Date
	   Definition:  A date associated with an event in the life cycle of the
    	   	         resource.
	   Comment:     Typically, Date will be associated with the creation or
	                availability of the resource.  Recommended best practice
	                for encoding the date value is defined in a profile of
        	        ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.



--danbri

Howdy,

This was in keeping with the examples in the 0.91 spec[1] for
backward compatibility in the RSS091 module.

All examples in the 1.0 proposal, however, use ISO 8601[2]:

   <dc:date>2000-01-01T12:00+00:00</dc:date>

I've fixed the RSS091 module examples to use RFC 822 (in both the spec and
modules documents) for consistency's (and backward-compatibility's) sake.

Thanks for pointing out that confusion, both of you.

Continuing on, however, I find ISO 8601 to be both human grok'able and
machine parseable.

Rael

On Tue, 15 Aug 2000, Aaron Swartz wrote:

> David King <david.king@...> wrote:
>
> > When a date is needed anywhere in RSS 1.0, I would urge that a format
> > such as the one in RFC 822 _not_ be used...
> > ...The easiest date format I've worked with by far is the UNIX timestamp
> > (the number of seconds since the Unix Epoch - January 1 1970 00:00:00
> > GMT).
>
> UNIX timestamp is fine with me, it's the standard format for the language I
> use (Tcl). I only suggested RFC 822 for consistency, but you bring up a good
> point. The only thing is that UNIX timestamp isn't much of a standard, and
> will cause problems when it overflows the integer (~2036, IIRC), but that
> isn't much of a deal for me. Anyone else have concerns?
>
> --
>         Aaron Swartz         |"This information is top security.
> <http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
>   <http://www.theinfo.org/>  |             - Marshall McLuhan
>
>
>
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
>
>
>
>

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------

[1] http://my.netscape.com/publish/help/mnn20/quickstart.html#step_2
[2] http://www.uic.edu/year2000/datefmt.html

On Tue, Aug 15, 2000 at 02:46:28PM -0500, Aaron Swartz wrote:
> David King <david.king@...> wrote:
>
> > When a date is needed anywhere in RSS 1.0, I would urge that a format
> > such as the one in RFC 822 _not_ be used...
> > ...The easiest date format I've worked with by far is the UNIX timestamp
> > (the number of seconds since the Unix Epoch - January 1 1970 00:00:00
> > GMT).
>
> UNIX timestamp is fine with me, it's the standard format for the language I
> use (Tcl). I only suggested RFC 822 for consistency, but you bring up a good
> point. The only thing is that UNIX timestamp isn't much of a standard, and
> will cause problems when it overflows the integer (~2036, IIRC), but that
> isn't much of a deal for me. Anyone else have concerns?

http://www.uic.edu/year2000/datefmt.html

ISO 8601 is the right format for dates

-- Edd

David King <david.king@...> wrote:

> When a date is needed anywhere in RSS 1.0, I would urge that a format
> such as the one in RFC 822 _not_ be used...
> ...The easiest date format I've worked with by far is the UNIX timestamp
> (the number of seconds since the Unix Epoch - January 1 1970 00:00:00
> GMT).

UNIX timestamp is fine with me, it's the standard format for the language I
use (Tcl). I only suggested RFC 822 for consistency, but you bring up a good
point. The only thing is that UNIX timestamp isn't much of a standard, and
will cause problems when it overflows the integer (~2036, IIRC), but that
isn't much of a deal for me. Anyone else have concerns?

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Aaron Swartz wrote:
> > Proposed addition to the syndication module: the publish-date of the
article.
>
> The other question is what is the proper date format. I suggest using RFC
> 822 to be consistent with RSS091 values.

When a date is needed anywhere in RSS 1.0, I would urge that a format
such as the one in RFC 822 _not_ be used.  It is notoriously annoying to
parse.  Mostly a result of certain parts being optional and things such
as names for days are used.  Not to mention that the year is expressed
in 2-digit form.

The easiest date format I've worked with by far is the UNIX timestamp
(the number of seconds since the Unix Epoch - January 1 1970 00:00:00
GMT).  To the naked eye, it's just an integer.  However, it takes the
formatting issues off of the RSS standard and allows the developer to
display the date however they want.  No need to worry about parsing a
date and then displaying it to the user in a decent format...oh joy!

I can't imagine any language that wouldn't have some kind of ability to
take a timestamp and easily format the date however the developer
wanted.  I am assuming that languages would simulate the timestamp on NT
machines to be the same as they are on UNIX boxes (as PHP appears to
do).

-David King

Gabe Beged-Dov <begeddov@...> wrote:

> Below is an example of using repeating properties ala the
> taxonomy module.

I've been playing around with this in SiRPAC and it looks like the best
solution. Thanks for your help! Another XMLNS-newbie question:

If I want to be able to embed XHTML as content, is there a way to say that
all of the following should be evaluated using the XHTML namespace? My guess
is that it would look like this:

   <c:content>
     <rdf:Description>
       <c:format>xhtml</c:format>
       <rdf:value rdf:parseType="Literal"
xmlns="http://www.w3.org/1999/xhtml">
          This is a demonstration of <strong>XHTML</strong> in RSS!
       </rdf:value>
     </rdf:Description>
   </c:content>

Is this correct? Can namespaces be nested like this?

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Rael Dornfest <rael@...> wrote:

> Or indeed, multiple possible images of different sizes and/or resolutions,
> perhaps?

I think both would be useful.

> We didn't want to deprecate anything that might affect backward
> compatibility.

How does deprecation affect backward compatibility? While I appreciate the
work done to make sure 1.0 is backward compatible, I'd hate to see the
baggage (textinput and image) left over from Netscape hobble the spec as it
moves forward.

Textinput and image are very much Netscape-specific, and work best in
designs that work like My Netscape does. I'd like to see RSS move forward
and drop these legacy values. However, I do see your reasoning and it makes
sense to keep image for the time being and add additional functionality
through modules. It just seems a little odd with some values seemingly
"blessed" by the spec and others having to be added on with namespaces. Oh
well.

>> Possible additions (to fit in somewhere): an author metadata (pointing to an
>> email address or a website for the author of the item) ...
> Some of this may be found in the Dublin Core elements in the third full
> example in the spec[14].

Oh, good point. I had forgotten about DC.

>> ... and persistent IDs
>> for items (so that corrections to an RSS file don't cause aggregators to
>> interpret it as a new item, thus duplicating the item).
> Good idea.  I had something like this in my ultra-old RSSx straw-man.
> It consisted of concatenated URL and date.  Dublin Core, I believe,
> can be brought into play here too.

Yes, the dc:identifier property would work nicely, the question is what to
put in it. URL and date would work, although it would look a bit odd and
would quite make sense as a URL. Of course, this goes well with my other
suggestion:

> Proposed addition to the syndication module: the publish-date of the article.

The other question is what is the proper date format. I suggest using RFC
822 to be consistent with RSS091 values.

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Jonathan Eisenzopf <eisen@...> wrote:

>> Why did you choose a closed process rather than an open one?
> To expedite the process and avoid political infighting.

OK, if there was ever a spec fraught with politics, it's probably RSS. This,
along with the comments from Rael pretty much explain everything. Thanks. I
just wanted to understand where you're coming from -- it makes total sense
and I totally agree.

Thanks for your hard work,

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Hi Eric,

Thanks for the great tools. I looked at the output example and there
are a few diffs from the spec. You list the namespace for rss091 as
"http://purl.org/rss/modules/#rss091/" rather than
"http://purl.org/rss/modules/rss091/". There is also an inchannel
property on the channel resource. The spec doesn't have that.

Gabe

Eric van der Vlist wrote:
>
> Hi,
>
> A set of XSLT stylesheets is available on 4xt to translate RSS 0.9 and
> 0.9.1 documents into the recently announced RSS 1.0 format, together
> with Java classes aimed at facilitating the transformation.

>
> These stylesheets, which can be used separately from the associated Java
> classes, are translating older RSS format (detected through the
> namespaces being used) into RSS 1.0.
>
> RSS 0.9 is translated into RSS 1.0 core, while RSS 0.9.1 is translated
> into RSS 1.0 using the RSS091 module for the elements that are specific
> to RSS 0.9.1.
>
> The java classes allow to skip the access to the RSS 0.9.1 DTD to
> process RSS 0.9.1 documents without network access, to force the reading
> of a DTD containing the definition of the HTML predefined entities which
> are allowed without DTD per RSS 0.9 specification, to improve the
> presentation of the converted document and to translate the non ASCII
> characters into their XML numerical representation.
>
> A set of real world examples is presented (each .in file being input,
> while the corresponding .out is the result) and RSS 1.0 feeds using
> these stylesheets for 4xt (http://4xt.org/news/general.rss10) and XMLfr
> (http://xmlfr.org/actualites/general.rss10) are immediately available.
>
> These tools are available from the following locations:
>
> http://www.egroups.com/files/rss-dev/Tools/ (download)
> http://4xt.org/downloads/rss/ (browse and download)
>
> I hope you'll find them useful.
>
> Eric
> --
> ------------------------------------------------------------------------
> Eric van der Vlist       Dyomedea                    http://dyomedea.com
> http://xmlfr.org         http://4xt.org              http://ducotede.com
> ------------------------------------------------------------------------
>
>
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com

--
---------------------------
http://www.jfinity.com/gabe

Aaron Swartz wrote:
>
> Jonathan Eisenzopf <eisen@...> wrote:
>
> > We've already received support from publishers and aggrigators.
> > The first version has been released and is stable. We are using
> > RSS 0.9 as a base, which has been out for quite a while. As with
> > any spec, I'm sure it will be refined.
>
> OK, so this brings up the questions I had in my other email:
>
> Who wrote this spec?
The authors are listed in the spec.

>How did they get chosen?
There was never a choosing really. It was a group of RSS and XML
experts.

>How did they write it?
We email discussions that convered the requirements that people
were requesting, identified the limitations of the current RSS
versions, and fit the pieces together from there.

> Will
> transcripts of that discussion be made available?
Probably not.

> Why did you choose a closed process rather than an open one?
To expedite the process and avoid political infighting.

> Don't misunderstand - I'm very thankful for the work you've done, just
> curious why you've dropped a finished spec into our laps without asking for
> public input. I'd appreciate it if you could explain a bit more about the
> thinking behind the process.
>
We only developed a first cut of the spec. It's now open for
public input.

--
Jonathan Eisenzopf    |  http://motherofperl.com
eisen@...       |  http://perlxml.com
Perl Hacker           |  http://dc.pm.org

Hi,

A set of XSLT stylesheets is available on 4xt to translate RSS 0.9 and
0.9.1 documents into the recently announced RSS 1.0 format, together
with Java classes aimed at facilitating the transformation.

These stylesheets, which can be used separately from the associated Java
classes, are translating older RSS format (detected through the
namespaces being used) into RSS 1.0.

RSS 0.9 is translated into RSS 1.0 core, while RSS 0.9.1 is translated
into RSS 1.0 using the RSS091 module for the elements that are specific
to RSS 0.9.1.

The java classes allow to skip the access to the RSS 0.9.1 DTD to
process RSS 0.9.1 documents without network access, to force the reading
of a DTD containing the definition of the HTML predefined entities which
are allowed without DTD per RSS 0.9 specification, to improve the
presentation of the converted document and to translate the non ASCII
characters into their XML numerical representation.

A set of real world examples is presented (each .in file being input,
while the corresponding .out is the result) and RSS 1.0 feeds using
these stylesheets for 4xt (http://4xt.org/news/general.rss10) and XMLfr
(http://xmlfr.org/actualites/general.rss10) are immediately available.

These tools are available from the following locations:

http://www.egroups.com/files/rss-dev/Tools/ (download)
http://4xt.org/downloads/rss/ (browse and download)

I hope you'll find them useful.

Eric
--
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------

Howdy, Aaron.

On Mon, 14 Aug 2000, Aaron Swartz wrote:

> How was the spec developed? Was it done through email discussion between the
> authors? If so, why did you choose this route, instead of a more public
> method? Would you be open to making the archives of this discussion
> available, so we could see the reasons behind some of the decisions?

I'll take your questions as an opportunity to provide a little background
for those just joining us.

You probably recall much of the back and forth on the Syndication
mailing list following my RSS Modularization Demonstration[1] and
subsequent "Spec(ish)"[2].  The debate revolved, for the most part,
around in-core flat extension of RSS (adding n new elements to 0.91)
versus relational (using XML Namespace-based modularity)[3].

My initial "Spec(ish)" and demonstration, while providing a useful
bit of visualization, were rather crude.  On the advice of Dave Winer
[4][5] and wanting to rethink various assumptions (both my own and
those of the RSS developers over time), I set about writing up a more
formal proposal.

In the midst of a discussion on my proposed Threading module, Eric
van der Vlist made an astute observation (and one I'd been glancing
at myself):

   Eric van der Vlist wrote:

   > The functionality is real nice, but shouldn't we consider using RDF ?
   > (I am afraid we might be reinventing RDF statement ;=)

   I wrote:

   "...which brings us back to DO..."  I was wondering how long it would
   take.  What does the "R" in "RSS" stand for again? ;-)[6]

He went on to point out that everyone was dancing around RDF, wanting
some of its flavour and features, but not the RDF name[7].  My argument
against RDF[8] was simply backward compatibility with RSS 0.91 and the
possible confusion value of RDF if not done right.

RSS 0.9 had indeed had a "nod" to RDF -- outer rdf:RDF element -- but
this had been removed in 0.91.  Questioning my assumptions on how hard
it would be to reintroduce RDF, I experimented with "putting the toothpaste
back into the tube" if you will.  While introducing RDF into RSS 0.91 was
a simple enough task in itself, there was that backward compatibility
issue.

As I bounced ideas off Eric and others, they became interested in the
puzzle and rolled up their sleeves.  We bandied about various ideas before
I hit upon it: why not simply start with that RDF nod already present in
RSS 0.9?  Surely that would provide a starting point upon which to build.
With vi, the W3C's handy-dandy SIRPAC-based visualization tool[9] (I
like pictures), etc, we set about building on 0.9, testing for RDF-compliance
and backward-compatibility using some RSS tools (XML::RSS, for one).  I was
working upon the assumption that many of the RSS tools and scriptlets folks
were using to parse RSS simply ignored what they didn't understand -- namely
attributes, namespace bits and pieces, and even ad-hoc elements providing
they did not affect the overall structure of the RSS document.

It didn't take long to realize that only a spoonful or three of syntactic
sugar would make RSS 0.9 RDF-sound and also provide for XML Namespace-based
modular extension.  We wrote it up, incorporated some of the earlier
module thoughts and proposals[10], and announced it here, on RSS-DEV
and other appropriate mailing lists today.

Quite a treatise that turned into; it certainly is some good organic
growth -- and interesting, hopefully.

> How "final" is the spec? Is it stable enough to begin publishing/aggregating
> in? Do you still expect discussion on it? Will discussion be able to impact
> the final version of the 1.0 spec or will it go into a future version?

Proposals are, I believe, the beginning (or at least the middle) of a
conversation[11], not the end.  It is for this reason that we chose to
start a mailing list-based working group -- open, unmoderated, and
publically-viewable -- and why we invited members of the RSS, syndication,
RDF, and various other communities to come take a gander and chat.

At the same time, I do want to encourage adoption at least alongside
RSS 0.9, 0.91, ScriptingNews, and other flavours.  I've done just that
with Meerkat[12] and ask folks to start implementing at least the core,
seeing where their needs are, and suggesting extensions.

> Do you plan to update http://weblogs.oreillynet.com/rss/ which is where
> http://purl.org/rss/ points to?

Heh.  I've uploaded all of these files for posterity to RSS-DEV's
"Defunct" file folder[13].  I've also pointed the /rss/ and /rss/modules/
PURLs to the current RSS 1.0 Specification and RSS 1.0 Modules documents,
respectively.  The weblogs.oreillynet.com/rss site will be shut down
shortly (I want to clean up loose ends/links first).

> Sorry, just sort of taken off guard by the sudden appearance of the spec?
>
> A few thoughts:
>
> I think the image element should also be deprecated and perhaps replaced by
> a module that allows per-item images (like Slashdot's "icons").

Or indeed, multiple possible images of different sizes and/or resolutions,
perhaps?

We didn't want to deprecate anything that might affect backward
compatibility.

> Proposed addition to the syndication module: the publish-date of the
> article.
>
> Possible additions (to fit in somewhere): an author metadata (pointing to an
> email address or a website for the author of the item) ...

Some of this may be found in the Dublin Core elements in the third full
example in the spec[14].

> ... and persistent IDs
> for items (so that corrections to an RSS file don't cause aggregators to
> interpret it as a new item, thus duplicating the item).

Good idea.  I had something like this in my ultra-old RSSx straw-man.
It consisted of concatenated URL and date.  Dublin Core, I believe,
can be brought into play here too.

> Also, if I were to publish comments on articles in RSS, how would I say that
> the comment refers to a specific article. Is this another module? I have a
> feeling this might be supported in RDF, but I'm not sure how.

Heh.  This relates to the inchannel RDF resource and position attributes.
I'll let Dan and/or Gabe jump in here.

> In conclusion, thanks to all the authors for their hard work and coming out
> with a really nice spec. I'm glad to see progress in the RSS format and even
> happier to see that RDF is back!

Glad you feel that way; and glad you're rolling up your sleeves as usual.

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------

[1]  http://www.egroups.com/message/syndication/188
[2]  http://www.egroups.com/message/syndication/214
[3]  http://www.xmlhack.com/read.php?item=621
[4]  http://www.egroups.com/message/syndication/202
[5]  http://www.egroups.com/message/syndication/218?&start=189
[6]  http://www.egroups.com/message/syndication/204
[7]  http://www.egroups.com/message/syndication/205
[8]  http://www.egroups.com/message/syndication/207
[9]  http://jigsaw.w3.org:8000/description
[10] http://weblogs.oreillynet.com/rss/modules
[11] http://www.egroups.com/message/syndication/206
[13] http://www.egroups.com/files/rss-dev/Defunct/Modular_RSS_Specish/
[14] http://www.egroups.com/files/rss-dev/specification.html#s7_1.0w_modules

Aaron Swartz wrote:
> Gabe Beged-Dov <begeddov@...> wrote:

> That's a good point - weblogs is probably a bad name for it. Maybe content?

content sounds like a reasonable interim name.

> As I understand it, the problem is that RDF is trying to create triplets
> saying that -weblogs:content- is the -content- of -URL-. So the problem is
> that I'm adding two properties, thus overloading the triplet. Am I right so
> far?

There are various ways to think about RDF. Trying to visualize the
directed labeled graph is one good way. The nodes of the graph are the
resources and the labeled arcs are the properties. The combination of
the source node, the arc and the target node is the triple that the
RDF formal model talks about. In the case of your example, the initial
start node is the item resource, the arc is labeled with
"weblogs:content" (content:foo below) and the value is either a
well-formed XML literal or another resource. One tweak is that RDF
allows a node to have multiple outbound arcs with the same label, i.e.
repeating properties (see below for an example).

> So it seems that perhaps the best solution would be to define three
> different possible tags. So it'd look like (assuming use of the new
> namespace content):
>
> <item>
> <content:xhtml rdf:parseType="Literal">
>     This is a demonstration of <strong>XHTML</strong> in RSS!
> </content:xhtml>
> <content:html><[![CDATA
>     This is a demonstration of <b>HTML</b> in RSS!
> ]]></content:html>
> <content:text>
>     This is a demonstration of **plain text** in RSS!
> </content:text>
> </item>
>
> This has the benefit of allowing the use of multiple formats in one RSS
> file, but the downside that it's not very extensible -- you'd have to update
> the module every time you wanted to add a new format.

The support of multiple representations can be handled in quite a few
different ways. Alternate representations can be seen as a special
case of multiple representations. RDF even has a built-in way to do
this using rdf:Alt containers [1].  Another tack is not to explicitly
encode the fact that the set of values are alternatives and simply
list them. This can be done either with repeating properties or a
container. The taxonomy module [2] uses repeating properties for
providing multiple subjects for an item. You could do the same thing
for content. Below is an example of using repeating properties ala the
taxonomy module. Note that you only have to specify
rdf:parseType="Literal" if the contents of the property has markup
that is not part of your graph. In the example only the first property
actually has markup. The second is using CDATA and the third is text.
Therefore, only the first rdf:value's contents have to be escaped.

<item>
   <c:content>
     <rdf:Description>
       <c:format>xhtml</c:format>
       <rdf:value rdf:parseType="Literal">
          This is a demonstration of <strong>XHTML</strong> in RSS!
       </rdf:value>
     </rdf:Description>
   </c:content>
   <c:content>
     <rdf:Description>
       <c:format>html</c: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>
   </c:content>
   <c:content>
     <rdf:Description>
       <c:format>text</c:format>
       <rdf:value>This is a demonstration of **plain text** in
RSS!</rdf:value>
     </rdf:Description>
   </c:content>
</item>

Gabe


[1] http://www.w3.org/TR/REC-rdf-syntax/#containers
[2] http://www.egroups.com/files/rss-dev/modules.html#s3.4

--
---------------------------
http://www.jfinity.com/gabe

R.V. Guha has released RSS2RDF, an on-the-fly translator from RSS 0.9 or
0.91 to RSS 1.0 -- as defined by the proposed specification at:

   http://purl.org/rss/1.0/

RSS2RDF is written in C for speed, makes use of Expat as its XML parser,
and runs both from the command-line or as a CGI.

MPL'd source and Linux binary are available for download at:

   http://www.guha.com/rss2rdf/

A Web-based conversion service using RSS2RDF has been made available
online at:

   http://purl.org/rss/1.0/convert

Usage:

   http://purl.org/rss/1.0/convert?url={rss_source}

Example:

lynx -source \
  'http://purl.org/rss/2.0/convert?url=http://freshmeat.net/backend/fm.rdf'

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:rss091="http://purl.org/rss/1.0/modules/rss091/"
          xmlns="http://purl.org/rss/1.0/">

<!-- Translated from RSS 0.91 by RSS2RDF -->

<channel   rdf:about="http://freshmeat.net">
     <rss091:language>en-us</rss091:language>
     <description>the one-stop-shop for all your Linux software
needs</description>
     <link>http://freshmeat.net</link>
     <title>freshmeat.net</title>
</channel>

...

Enjoy!

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------

Jonathan Eisenzopf <eisen@...> wrote:

> We've already received support from publishers and aggrigators.
> The first version has been released and is stable. We are using
> RSS 0.9 as a base, which has been out for quite a while. As with
> any spec, I'm sure it will be refined.

OK, so this brings up the questions I had in my other email:

Who wrote this spec? How did they get chosen? How did they write it? Will
transcripts of that discussion be made available? Why did you choose a
closed process rather than an open one?

Don't misunderstand - I'm very thankful for the work you've done, just
curious why you've dropped a finished spec into our laps without asking for
public input. I'd appreciate it if you could explain a bit more about the
thinking behind the process.

Thanks a lot,

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Aaron Swartz wrote:
>
> Jonathan Eisenzopf <eisen@...> wrote:
>
> > Just uploaded a new release of the XML::RSS module for review
> > before I post it to CPAN. Feedback would be appreciated.
>
> The readme file doesn't seem to be updated (it still says version 0.8) but
> it's great to see support for RSS 1.0 so quickly! Since (I would guess) a
> large number of RSS aggregators use the XML::RSS Module, this is great news.
> Of course, it brings up the question -- how "finished" is the spec, should
> aggregators be supporting it yet? Should publishers be publishing in it?
>
We've already received support from publishers and aggrigators.
The first version has been released and is stable. We are using
RSS 0.9 as a base, which has been out for quite a while. As with
any spec, I'm sure it will be refined.

--
Jonathan Eisenzopf    |  http://motherofperl.com
eisen@...       |  http://perlxml.com
Perl Hacker           |  http://dc.pm.org

Gabe Beged-Dov <begeddov@...> wrote:

> Thanks for the quick proposal.

No problem, I've been thinking about creating an all new format like it for
a while, and slipping it into RSS seemed like the perfect opportunity.

> My only general comment/question is whether its broader
> than just weblogs? I think that adding a content module to RSS1
> is a great area to push on.

That's a good point - weblogs is probably a bad name for it. Maybe content?
Any other suggestions?

> The module as described doesn't quite fit into the RDF model. You are
> hanging a property with the label "weblogs:content" off of a resource
> of type item. A property can only have one value. The two values in
> your example are the "format" attribute and the element's content.

Oh, I see. I'm sorry -- I'm not too familiar with the actual syntax of RDF
so I didn't know about that. But while I may not know too much about RDF
syntax, I am very much in support of the idea, and thus I'm glad you decided
to support it with RSS 1.0.

As I understand it, the problem is that RDF is trying to create triplets
saying that -weblogs:content- is the -content- of -URL-. So the problem is
that I'm adding two properties, thus overloading the triplet. Am I right so
far?

So it seems that perhaps the best solution would be to define three
different possible tags. So it'd look like (assuming use of the new
namespace content):

<item>
<content:xhtml rdf:parseType="Literal">
     This is a demonstration of <strong>XHTML</strong> in RSS!
</content:xhtml>
<content:html><[![CDATA
     This is a demonstration of <b>HTML</b> in RSS!
]]></content:html>
<content:text>
     This is a demonstration of **plain text** in RSS!
</content:text>
</item>

This has the benefit of allowing the use of multiple formats in one RSS
file, but the downside that it's not very extensible -- you'd have to update
the module every time you wanted to add a new format.

Thoughts?

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Aaron Swartz wrote:
>
> Jonathan Eisenzopf <eisen@...> wrote:
>
> > Just uploaded a new release of the XML::RSS module for review
> > before I post it to CPAN. Feedback would be appreciated.
>
> The readme file doesn't seem to be updated (it still says version 0.8) but
> it's great to see support for RSS 1.0 so quickly! Since (I would guess) a
> large number of RSS aggregators use the XML::RSS Module, this is great news.
> Of course, it brings up the question -- how "finished" is the spec, should
> aggregators be supporting it yet? Should publishers be publishing in it?
>
Thx. Will fix.

--
Jonathan Eisenzopf    |  http://motherofperl.com
eisen@...       |  http://perlxml.com
Perl Hacker           |  http://dc.pm.org

Hi Aaron,

Thanks for the quick proposal. I'm only responding to the RDF related
aspects. I think that adding a content module to RSS1 is a great area
to push on. My only general comment/question is whether its broader
than just weblogs? Now onto RDF issues:

The module as described doesn't quite fit into the RDF model. You are
hanging a property with the label "weblogs:content" off of a resource
of type item. A property can only have one value. The two values in
your example are the "format" attribute and the element's content.

If you want to effectively have more than one value for a property
there are various ways to do that. If you want to immediately escape
into non-rdf interpreted content you could use rdf:parseType="Literal"
on the property and then use any well-formed XML as the content of the
property. An RDF processor would then do XML checking on the contents
and keep it as the value. For example:

  <item>
   <weblogs:content rdf:parseType="Literal">
     <weblogs:format>text/html</weblogs:format>
     <weblogs:value>
       Hey I found the <a
href="http://www.50megs.com/webfitz/">Billboard Top
       100</a> for 1961-72.<br><br> <!-- etc.. -->
     </weblogs:value>
   </weblogs:content>
  </item>

I could have used mixed content (i.e. PCDATA and elements intermixed)
rather than adding a wrapper element (weblogs:value). You make the
call.

Alternatively, you could make the value of the weblogs:content
property an RDF resource. You could then hang one or more properties
off of that resource that represents the content of the item. Here is
an example:

  <item>
   <weblogs:content>
     <rdf:Description>
       <weblogs:format>text/html</weblogs:format>
       <rdf:value rdf:parseType="Literal">
          Hey I found the <a
href="http://www.50megs.com/webfitz/">Billboard Top
          100</a> for 1961-72.<br><br> <!-- etc.. -->
       </weblogs:value>
     </rdf:Description>
   </weblogs:content>
  </item>

Notice that the actual html markup has migrated to the rdf:value
property of the anonymous resource that is now the value of the
weblogs:content property. Since the value of the rdf:value property
containts markup, it still needs to be escaped by using
rdf:parseType="Literal". This idiom of using an intermediate node
which has an rdf:value property and zero or more sibling properties is
well-described in the DC-in-RDF working draft [1]. The sibling
properties provide qualification for the contents of the rdf:value. In
this case the format property says how to interpret the value. Since
two of the three authors of DC-in-RDF are also authors of RSS1, maybe
they can chime in with whether I've made a mess of things :-)

Hope this helps,

Gabe

[1] http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/

Howdy,

On Mon, 14 Aug 2000, Edd Dumbill wrote:

> On Mon, Aug 14, 2000 at 05:01:27PM -0500, Aaron Swartz wrote:
> > Of course, it brings up the question -- how "finished" is the spec, should
> > aggregators be supporting it yet? Should publishers be publishing in it?
>
> Rael will correct me if I'm wrong here, but I think the spec is at the
> stage where implementation in earnest is invited in order to iron out
> the final bits and get some implementation experience.

Yes indeed.  Meerkat, our Web-based syndicated content reader, already
provides an feed conformant with the RSS 1.0 proposal and sporting some
module usage:

   http://meerkat.oreillynet.com/?_fl=rss10

This, of course, plays nicely with Meerkat's regular Flavour and Recipe
features -- see:

   Meerkat: An Open Service API
   http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html

> When I get a few spare cycles (heh!) I'll be hacking my Zope RSS
> product, SiteSummary, to add RSS 1.0 support. I also intend that xmlhack
> should publish its RSS file in v1.0 as well, as soon as I can make the
> needed changes.

I will clean up and post/upload a simple document to be plopped into the
Zope Squishdot product to provide conformant feeds in a while.

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------

On Mon, Aug 14, 2000 at 05:01:27PM -0500, Aaron Swartz wrote:
> Of course, it brings up the question -- how "finished" is the spec, should
> aggregators be supporting it yet? Should publishers be publishing in it?

Rael will correct me if I'm wrong here, but I think the spec is at the
stage where implementation in earnest is invited in order to iron out
the final bits and get some implementation experience.

When I get a few spare cycles (heh!) I'll be hacking my Zope RSS
product, SiteSummary, to add RSS 1.0 support. I also intend that xmlhack
should publish its RSS file in v1.0 as well, as soon as I can make the
needed changes.

-- Edd

Jonathan Eisenzopf <eisen@...> wrote:

> Just uploaded a new release of the XML::RSS module for review
> before I post it to CPAN. Feedback would be appreciated.

The readme file doesn't seem to be updated (it still says version 0.8) but
it's great to see support for RSS 1.0 so quickly! Since (I would guess) a
large number of RSS aggregators use the XML::RSS Module, this is great news.
Of course, it brings up the question -- how "finished" is the spec, should
aggregators be supporting it yet? Should publishers be publishing in it?

Thanks,

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the rss-dev
group.

   File        : /Tools/XML-RSS-0.9.tar.gz
   Uploaded by : eisen@...
   Description : Perl RSS module

You can access this file at the URL

http://www.egroups.com/files/rss-dev/Tools/XML-RSS-0%2E9%2Etar%2Egz

To learn more about eGroups file sharing, please visit

http://www.egroups.com/help/files.html


Regards,

eisen@...

Just uploaded a new release of the XML::RSS module for review
before I post it to CPAN. Feedback would be appreciated.

--
Jonathan Eisenzopf    |  http://motherofperl.com
eisen@...       |  http://perlxml.com
Perl Hacker           |  http://dc.pm.org

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the rss-dev
group.

   File        : /XML-RSS-0.9.tar.gz
   Uploaded by : eisen@...
   Description : Perl RSS module

You can access this file at the URL

http://www.egroups.com/files/rss-dev/XML-RSS-0%2E9%2Etar%2Egz

To learn more about eGroups file sharing, please visit

http://www.egroups.com/help/files.html


Regards,

eisen@...

I'd like to propose the following additional module to the spec. Feedback
and comments are of course welcome, if there is support for the module I'd
appreciate it if Rael (or whomever) would rewrite it (so it's more in line
with the rest of the spec) and include it in the modules list.

Thanks for the feedback in advance,

Aaron

----

Weblogs are a popular way of publishing personal content on the Internet.
Currently, the only real syndication format for weblogs is UserLand's
ScriptingNews format. The weblogs module will allow weblogs to syndicate
their content using RSS. The content element can contain either plain text
(text/plain), XHTML (text/xml), or HTML (text/html - for compatibility with
non-XHTML sites). This is identified through the use of the format
attribute. The content can be included through use of a CDATA element or the
quoting of the HTML/XML attributes. (Question: Should XHTML be quoted?)

Namespace Declarations:
     xmlns:weblogs="http://purl.org/rss/1.0/modules/weblogs/"

<item> Elements:
     <weblogs:content format="content_format"> ( #PCDATA )


Example:

<?xml version="1.0"?>

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:weblogs="http://purl.org/rss/1.0/modules/weblogs/"
   xmlns="http://purl.org/rss/1.0/"
>

   <channel rdf:about="http://scriptingnews.userland.com/xml/rss.xml">
     <title>Scripting News</title>
     <link>http://www.scripting.com/</link>
     <description>
       Dave Winer's weblog, covering scripting, communications, our galaxy.
     </description>
   </channel>

   <item
  rdf:about="http://scriptingnews.userland.com/backIssues/2000/08/14#music">
     <inchannel
rdf:resource="http://scriptingnews.userland.com/xml/rss.xml"/>
     <title>Music!</title>

<link>http://scriptingnews.userland.com/backIssues/2000/08/14#music</link>
     <weblogs:content format="text/html">
      <![CDATA[
Hey I found the <a href="http://www.50megs.com/webfitz/">Billboard Top
100</a> for 1961-72.<br><br>

Today's song: <a
href="http://www.ugcs.caltech.edu/~harel/lyrics/Betty_Its_In_His_Kiss.html">
It's In His Kiss</a>. <i>Shoop shoop!</i><br><br>


<a href="http://www.history-of-rock.com/chiffons.htm">In 1960</a>, the
Chiffons formed at James Monroe High School in the Bronx, New York<br><br>
]]>
     </weblogs:content>
   </item>

</rdf:RDF>


--
Aaron Swartz <aswartz@...>|  advertising advertises advertising
<http://www.swartzfam.com/aaron/> |         - Marshall McLuhan
  AIM: Jedi of Pi | ICQ: 33158237  |   we don't  - <http://theinfo.org/>

A few questions:

How was the spec developed? Was it done through email discussion between the
authors? If so, why did you choose this route, instead of a more public
method? Would you be open to making the archives of this discussion
available, so we could see the reasons behind some of the decisions?

How "final" is the spec? Is it stable enough to begin publishing/aggregating
in? Do you still expect discussion on it? Will discussion be able to impact
the final version of the 1.0 spec or will it go into a future version?

Do you plan to update http://weblogs.oreillynet.com/rss/ which is where
http://purl.org/rss/ points to?

Sorry, just sort of taken off guard by the sudden appearance of the spec?

A few thoughts:

I think the image element should also be deprecated and perhaps replaced by
a module that allows per-item images (like Slashdot's "icons").

Proposed addition to the syndication module: the publish-date of the
article.

Possible additions (to fit in somewhere): an author metadata (pointing to an
email address or a website for the author of the item) and persistent IDs
for items (so that corrections to an RSS file don't cause aggregators to
interpret it as a new item, thus duplicating the item).

Also, if I were to publish comments on articles in RSS, how would I say that
the comment refers to a specific article. Is this another module? I have a
feeling this might be supported in RDF, but I'm not sure how.

In conclusion, thanks to all the authors for their hard work and coming out
with a really nice spec. I'm glad to see progress in the RSS format and even
happier to see that RDF is back!

Thanks for all your hard work,

--
         Aaron Swartz         |"This information is top security.
<http://swartzfam.com/aaron/>|     When you have read it, destroy yourself."
   <http://www.theinfo.org/>  |             - Marshall McLuhan

Howdy,

Welcome to the RSS-DEV mailing list, home of a working group for the
further development of RSS ("RDF Site Summary").

Abstract
--------
RSS ("RDF Site Summary") is a lightweight multipurpose
extensible metadata description and syndication format.  RSS is
an XML application, conforms to the W3C's RDF Specification
and is extensible via XML-namespace and/or RDF based modularization.

Design Goals
------------
The modular extension of existing RSS through XML Namespaces and RDF
stressing backward compatibility with RSS 0.9 for ease of adoption
by existing syndicated content producers.

Documents
---------
RSS 1.0 Specification Proposal
http://purl.org/rss/1.0/

RSS 1.0 Modules
http://purl.org/rss/1.0/modules/

Discussion
----------
Interested parties, please join the working group at:

   http://www.egroups.com/group/rss-dev

Regards,

Rael

------------------------------------------------------------------
   Rael Dornfest                  rael@...
   Maven,                         http://www.oreillynet.com/~rael
   The O'Reilly Network           http://meerkat.oreillynet.com
------------------------------------------------------------------