OK, first, my problem: taking data from a Slash database and encoding it so
it will be 1. legal XML, and 2. easily decoded back into something
resembling the original data.  This is compounded by the problem that some
people may put illegal data into the database to begin with (e.g., a lone
"&" should not ever be in a title or description).

Then, we want to decode the data reasonably.

All of the above also assumes that we are encoding from and decoding to
HTML.  If a user of our RSS file wants to then run something like
HTML::Entities::decode_entities() on the result, they can get a non-HTML
version of it.

The short of it is the program below.  It will take some data, encode it
for inclusion in an RSS file, then decode it to see what it would be on
output.  For example:

Original:
<em>I've "a" <a href="bio.html">"Bio"</a> && a
<Résumé!></em>

Encoded:
<em>I've &quot;a&quot; <a
href="bio.html">"Bio"</a> &amp;&amp; a
&#x3c;R&eacute;sumé!&#x3E;</em>

Decoded:
<em>I've "a" <a href="bio.html">"Bio"</a> && a
<Résumé!></em>

Note that in the original, we have a character (e with an acute accent)
that we want to have encoded.  We want to preserve the < and >, but we
don't want the < to become <, or the > to become >.

Anyway, if you can, please follow the code and let me know any problems you
have with our methods here.  I realize I might not be very clear; it's been
a long day.  Let me know if I can clarify anything for you.

Thanks,

--Chris


#!/usr/bin/perl -wl

use strict;
use XML::RSS;  # includes XML::Parser::Expat

my $text = <<EOT;
<em>I've "a" <a href="bio.html">"Bio"</a> && a
<Résumé!></em>
EOT

sub encode_text {
	 my($text) = @_;

	 # if there is an & that is not part of an entity, convert it
	 # to &
	 $text =~ s/&(?!#?[a-zA-Z0-9]+;)/&/g;

	 # convert & < > to XML entities
	 $text = XML::Parser::Expat->xml_escape($text, ">");

	 # convert ASCII-non-printable to numeric entities
	 $text =~ s/([^\s\040-\176])/ "&#" . ord($1) . ";" /ge;

	 return $text;
}

{
	 # for all following chars but &, convert entities back to
	 # the actual character

	 # for &, convert & back to &, but only if it is the
	 # beginning of an entity (like "&#32;")

	 # precompile these so we only do it once

	 my %e = qw(< lt > gt " quot ' apos & amp);
	 for my $chr (keys %e) {
		 my $word = $e{$chr};
		 my $ord = ord $chr;
		 my $hex = sprintf "%x", $ord;
		 $hex =~ s/([a-f])/[$1\U$1]/g;
		 my $regex = qq/&(?:$word|#$ord|#[xX]$hex);/;
		 $regex .= qq/(?=#?[a-zA-Z0-9]+;)/ if $chr eq "&";
		 $e{$chr} = qr/$regex/;
	 }

	 sub decode_text {
		 my($text) = @_;

		 # do & only _after_ the others
		 for my $chr ( (grep !/^&$/, keys %e), "&") {
			 $text =~ s/$e{$chr}/$chr/g;
		 }

		 return $text;
	 }
}

print $text;
print $text = encode_text($text);
print $text = decode_text($text);


__END__

--
Chris Nandor                      pudge@...    http://pudge.net/
Open Source Development Network    pudge@...     http://osdn.com/

A salutary lesson to us:
http://www.theregister.co.uk/content/28/16550.html

Seems it's all due to some magic charcters being escaped in the page layout
program, and the renderer then treating them as literal characters.


Let's be careful with those CDATA's !


--
Andy Dingley
+44 117 312 8701            +44 7970 468006

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        : /Modules/Proposed/mod_taxonomy-1-2.html
   Uploaded by : vdv@...
   Description : Taxonomy module. Proposition 1.2

You can access this file at the URL

http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_taxonomy-1-2.ht\
ml

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

vdv@...
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms

I have posted a new draft for the taxonomy module with the minimal
features that, IMHO, we need to include.

One thing that I find interesting is that a topic appears to be very
similar to a channel, the major difference being that the relation is
defined "the other way round": we give a list of items belonging to a
channel while be give a list of topic relevant for an item.

A part from this, a topic could be considered as a channel and I think
that even on a functional standpoint, this is making sense.

Thanks for your comments.

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

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        : /Modules/Proposed/mod_taxonomy-1-2.html
   Uploaded by : vdv@...
   Description : Taxonomy module. Proposition 1.2

You can access this file at the URL

http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_taxonomy-1-2.ht\
ml

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

vdv@...
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms







To unsubscribe from this group, send an email to:
rss-dev-unsubscribe@egroups.com

--- In rss-dev@y..., Eric van der Vlist <vdv@d...> wrote:
> I have posted a new draft for the taxonomy module with the minimal
> features that, IMHO, we need to include.
>
> One thing that I find interesting is that a topic appears to be very
> similar to a channel, the major difference being that the relation
is
> defined "the other way round": we give a list of items belonging to
a
> channel while be give a list of topic relevant for an item.
>
> A part from this, a topic could be considered as a channel and I
think
> that even on a functional standpoint, this is making sense.
>
Oh my. I think this is overly complex. Can we stop and think about
what we believe people will want a taxonomy module for? I'll
reiterate my personal need and vision for the taxonomy module.

I would like to have "What's Related" type links from RSS files. Yes,
it would be nice to have a list; one to a Dmoz directory, one to
Yahoo, one to my articles page, and one to one of Rael's articles. Of
course, to do this, I need to categorize the items. I can already
sorta do this with dc. But is sure would be nice to have a label and
URL to the category resource.

If I'm off base, perhaps someone can articulate the benefit of the
more complex model given that it will be more difficult to understand
and program than what has been proposed previously.

eisen@... <eisen@...> wrote:

> If I'm off base, perhaps someone can articulate the benefit of the
> more complex model given that it will be more difficult to understand
> and program than what has been proposed previously.

I don't see what's so complex about the model. Here's how I see it

item \           / link
item ----topic---- title
item /           \ more info

What model do you propose?

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Eric van der Vlist <vdv@...> wrote:

> One thing that I find interesting is that a topic appears to be very
> similar to a channel, the major difference being that the relation is
> defined "the other way round": we give a list of items belonging to a
> channel while be give a list of topic relevant for an item.

This is very insightful, and I think it needs to be developed.

Could we declare topic as a subclass of channel? That way all the elements
we use in channel could be used in topic (and would be pretty appropriate
too). I an also see aggregators building channels based on each topic, of
course they can't use the topic element to do it, since then it wouldn't be
valid RSS.

We also should think of ways to declare members of topics the other way
around. That is, I create a topic and state that is has x, y, and z as
members.

This should definitely be explored.

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

eisen@... wrote:
>
> Oh my. I think this is overly complex.

???

It's the most simple proposal we've done so far except the current one
that is not valid RDF !

> Can we stop and think about what we believe people will want a
> taxonomy module for?

I can't tell for "people", but as far as I am concerned I can tell that
all I need is to uniquely identify the topics that are related to an
item or channel for 2 purposes:

(1) to be able to say if items are related.
(2) to be able to display links for each topic on a page that will
display all the items related to this topic.

> I'll reiterate my personal need and vision for the taxonomy module.

My view -if you don't want to call it a vision- is that the taxonomy
module should be doing what DC subject does with URI identifiers instead
of text (sufficient to achieve (1)) and, optionally, give a concise
description of the topic (needed for (2)).

> I would like to have "What's Related" type links from RSS files. Yes,
> it would be nice to have a list; one to a Dmoz directory, one to
> Yahoo, one to my articles page, and one to one of Rael's articles. Of
> course, to do this, I need to categorize the items. I can already
> sorta do this with dc. But is sure would be nice to have a label and
> URL to the category resource.

Yes, it's what the taxonomy module does.

However, the discussion carried so far has shown:

1) using the dc:subject in place of what I have called "taxo:topics"
would be confusing since one would have to parse it before telling if
it's raw DC or taxo:module.
===> taxo:topics
2) "people" prefer to avoid multiple elements except within RDF
containers.
===> rdf:Bag/rdf:li
3) it is not valid RDF to define a value within a reference to a
resource, thus, to attach a label to a topic, it is better to dissociate
the reference (rdf:li resource=...) from the definition of this topic.
===> rdf:topic.

These choices are not always my preferred ones, I am just seeking a
consensus and I think this proposal is a fair compromise.

> If I'm off base, perhaps someone can articulate the benefit of the
> more complex model given that it will be more difficult to understand
> and program than what has been proposed previously.

What has been proposed previously is not a valid RDF document and most
of the RDF parser are blowing out when reading it.

I think it's a fair enough reason to change !

Eric

> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com

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

Aaron Swartz wrote:
>
> Eric van der Vlist <vdv@...> wrote:
>
> > One thing that I find interesting is that a topic appears to be very
> > similar to a channel, the major difference being that the relation is
> > defined "the other way round": we give a list of items belonging to a
> > channel while be give a list of topic relevant for an item.
>
> This is very insightful, and I think it needs to be developed.

:)

> Could we declare topic as a subclass of channel? That way all the elements
> we use in channel could be used in topic (and would be pretty appropriate
> too).

Yes. That's why I have given rather similar models ("title", "link",
"dc:*" and even "taxo:topics" are sub elements of both "channel" and
"taxo:topic").

We could add an "image"... I am less sure about "items" and "textinput"
and I have preferred "dc:description" to "description".

> I an also see aggregators building channels based on each topic, of
> course they can't use the topic element to do it, since then it wouldn't be
> valid RSS.

Yes, but it would be straightforward to derive.

> We also should think of ways to declare members of topics the other way
> around. That is, I create a topic and state that is has x, y, and z as
> members.

It *** seems *** easier and more natural to find the topics related to
an item when creating a RSS document than to find the items related to a
topic.

> This should definitely be explored.

If we go along this path, we might just call the topics "related
channels" and allow multiple channels definition in a RSS feed and|or go
on with the include module to define their locations.

When you think about it, it does make some sense.

However, if you think too much about it, all our objects (channels,
items, images, text inputs, topics) are RDF resources that could be
defined almost the same way and can be interchangeable.

For instance, if you have an item "belonging" to several channels, you
can define a channel with this item that is the collection of the
channels to which the item belongs and which items are the channels.

What I mean with this example is that if we go too far in this
direction, we end up with pure RDF and do not add much value any longer.

The added value of RSS is to give a predefined syntax with a
differentiation between the RDF objects and I think there is enough
difference to keep taxo:topic different yet similar to channels.

Eric
>
> --
> [ Aaron Swartz | me@... | http://www.aaronsw.com ]
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com

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

Redland RDF Application Framework 0.9.8
		 http://www.redland.opensource.ac.uk/

Redland 0.9.8 has been released and the main changes are:

* Added Tcl interface

* Added Rapier RDF parser, written by me (alpha quality) and made some
   changes to support it.  This is a slightly newer version than the
   first standalone release.

* More fixes to Perl interface to fix crashes

* Added Perl RDF::RSS method as_xhtml for simple RSS 1.0 to (X)HTML
   formatting.

The release consists of the full sources, RPM binaries and SRPMS
packages for RedHat Linux 6.2.  It is also available from the
Redland SourceForge mirror site at http://sourceforge.net/projects/librdf/

I post updates between releases to the Yahoo! Groups list at
http://groups.yahoo.com/group/redland/ and invite you to join if you
are interested.

Dave

I have updated the RSS 1.0 feed for XMLfr to implement the new proposal
for the taxonomy module:

http://xmlfr.org/actualites/general.rss10

Like for the previous version, the URIs used to identify the topics can
be derefenced producing a dynamic page querying rdfDB to get a list of
articles relevant for the topic.

Enjoy,

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

Eric van der Vlist <vdv@...> wrote:

>> Could we declare topic as a subclass of channel? That way all the elements
>> we use in channel could be used in topic (and would be pretty appropriate
>> too).
> Yes. That's why I have given rather similar models ("title", "link",
> "dc:*" and even "taxo:topics" are sub elements of both "channel" and
> "taxo:topic").
>
> We could add an "image"... I am less sure about "items" and "textinput"
> and I have preferred "dc:description" to "description".

Yeah, I can see how items and textinput would make less sense. (Textinput
actually never really made sense. ;-))

>> This should definitely be explored.
> If we go along this path, we might just call the topics "related
> channels" and allow multiple channels definition in a RSS feed and|or go
> on with the include module to define their locations.
>
> When you think about it, it does make some sense.

I think we should at least make this an option. How about, taxo:topics can
point to either a topic or a channel? And a taxo:topic can use any module
that specifies elements for an rss:channel (except where explicitly
disallowed).

> What I mean with this example is that if we go too far in this
> direction, we end up with pure RDF and do not add much value any longer.

Well, we add the value of a single allowed XML syntax, but I agree with your
main point.

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Hello,

I'm working with a group of servers that each host many nonprofit
websites.  http://sourceforge.net/projects/apc-aa/

These servers are setting up a syndication system between them for sharing
news alerts. http://plus.aldebaran.de/apc-aa/csnspec.html

We are planning on using
   RSS 1.0 + the DC module + some module for the full text of the alert
as the exchange format.

Does anyone have any suggestions for how to include the full text of the
news alert?  Is there something already available we could use?

I was thinking of something like:

<rdf:RDF
...
xmlns:ft="http://purl.org/fulltext/1.0/"
>

And then in the item, use:

<ft:text>This is the full text of the article.</ft:text>  OR
<ft:html>this is the <b>full</b>text of the article</ft:text>

Any thoughts would be greatly appreciated.

Michael

Michael deBeer <madebeer@...> wrote:

> Does anyone have any suggestions for how to include the full text of the
> news alert?  Is there something already available we could use?

I'd love it if you guys would test drive the content module:

http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.htm
l

If you're interested, I'll clean up the spec so you guys can use it.

Thanks,
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Nice work !

I have some comments ;=) about it, though...

Aaron Swartz wrote:
>
> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.html
>

1) About the "format".

I think we need 2 qualifiers: the type of document and its encoding that
may be independent.

By encoding, I mean "raw XML inline", "escaped text" (like a CDATA
section) or other XML friendly encodings such as "hex" or "base64".

The type of documents could be identified, like you've shown and like
RDDL is doing it by a mime type and/or for XML formats though a
namespace.

2) About the namespaces for attributes.

I think we need to follow what each vocabulary is defining !

If XHTML defines local attributes (or unqualified attributes like W3C
XML Schema is calling them), we should use local attributes in the
content module and we should not "qualify" them...

3) Repeated 2nd level elements.

I thought we had deprecated them (which is was a mistake IMHO), so you
can't have several content:content elements under a same item :(

I don't know if it's worth going through a rdf:Bag to reference/define a
set of contents, though.

What do you think ?

4) About the examples

I think it would be clearer to add a "<" sign in the text example and a
non well formed tag (such as <br> in the html example.

Also, shouldn't it be
<content:format
rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/text/plai\
n"/>

??

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

On Mon, 5 Feb 2001, Aaron Swartz wrote:
> > Does anyone have any suggestions for how to include the full text of the
> > news alert?  Is there something already available we could use?
>
> I'd love it if you guys would test drive the content module:
>
> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.html
>
> If you're interested, I'll clean up the spec so you guys can use it.

We are very interested.

Michael

BTW Our application is in php, so if you have php code snippets for doing
the various encodings/escapings mentioned in your example, they would be
appreciated.

Michael deBeer <madebeer@...> wrote:

>> If you're interested, I'll clean up the spec so you guys can use it.
> We are very interested.

Great! I'm working on cleaning up the spec to address Eric's concerns and
then I'll release it.

> BTW Our application is in php, so if you have php code snippets for doing
> the various encodings/escapings mentioned in your example, they would be
> appreciated.

I don't know PHP but I think others on this list might be able to provide
something.

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Eric van der Vlist <vdv@...> wrote:

>> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.html
> I think we need 2 qualifiers: the type of document and its encoding that
> may be independent.

OK, how about this --

Default encoding is encoded text, others can use an encoding element to
describe the encoding. I'm going to try and get the RDDL folks to put up a
page of XML encodings for us to use.

> If XHTML defines local attributes (or unqualified attributes like W3C
> XML Schema is calling them), we should use local attributes in the
> content module and we should not "qualify" them...

Oops, I had totally forgotten about this. You're right! This makes things
much easier.

> I thought we had deprecated them (which is was a mistake IMHO), so you
> can't have several content:content elements under a same item :(
>
> I don't know if it's worth going through a rdf:Bag to reference/define a
> set of contents, though.

You're right here too, I'll throw them in a bag.

> I think it would be clearer to add a "<" sign in the text example and a
> non well formed tag (such as <br> in the html example.

Ok, good idea.

> Also, shouldn't it be
> <content:format
> rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/text/pl
> ain"/>

Isn't that what it is?

I'll put up a new version of the spec later today.

Thanks for your feedback,

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

I've put up a new version of the content module:

http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.htm
l

I've got a new (valid RDF) syntax, added some of Eric's suggestions, and
made everything more clear. Here's what the syntax looks like at its
simplest:

<content:items><rdf:Bag><rdf:li>
   <content:item rdf:about="http://a.org/content.svg">
     <content:format rdf:resource="http://www.w3.org/2000/svg" />
   </content:item>
</rdf:li></rdf:Bag></content:items>

If there are no objections to it, I think I'll put it up for a poll on
whether to release it as 1.0.

(Oh, and if anyone else feels their name should go on the spec, please let
me know. I can't remember everyone who contributed.)

Thanks!
--
Aaron Swartz <me@...>|               RSS Info
   <http://www.aaronsw.com>   |   <http://www.blogspace.com/rss/>
AIM: JediOfPi | ICQ: 33158237| news and information on the RSS format

One of the cool things about having RSS as an RDF format (among others) is
the ability to use it to test out all of the new bleeding-edge RDF tools. On
the suggestion of DanBri, and thanks to the kind assistance of Sean Palmer,
I'm proud to present an example RSS file in the Notation3 language[1].

Notation3 is an RDF language designed to be easy to write and read in ASCII
environments (like email). It's very simple -- to write an RDF triple you
simply write:

<#subject-uri> <#predicate-uri> <#object-uri> .

(it has namespace prefixes too, of course) It also has a few more
complicated features like anonymous nodes, etc. but I won't get in to those.
Anyway, here's the first part of the W3C's RSS file[2] in Notation3:

@prefix : <http://purl.org/rss/1.0/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://www.w3.org/2000/08/w3c-synd/home.rss> a channel ;
   :title "The World Wide Web Consortium" ;
   :description "Leading the Web to its Full Potential..." ;
   :link "http://www.w3.org/" ;
   dc:date "2001-02-06T20:07:40Z" ;
   :items [ a rdf:Seq;
     rdf:_1 <http://www.w3.org/Graphics/SVG/Test/>;
     rdf:_2 <http://www.w3.org/2001/01/WSWS>;
     rdf:_3 <http://www.w3.org/TR/2001/WD-xml-infoset-20010202/>;
     rdf:_4 <http://www.w3.org/TR/2001/NOTE-xmldsig-p3p-profile-20010202/>;
     rdf:_5 <http://www.w3.org/2001/di/Activity> ] .

<http://www.w3.org/Graphics/SVG/Test/> a :item;
   :title "SVG Test Suite Available";
   :description
      """2 February 2001: The W3C Scalable Vector Graphics (SVG)
      Working Group has published an enhanced and updated version of the SVG
      Conformance Test Suite, the second public release. The results of
      testing six implementations against the test suite are also available.
      SVG is a language for describing two-dimensional vector, image, and
      text graphics in XML.""" ;
   :link <http://www.w3.org/Graphics/SVG/Test/>;
   dc:date "2001-02-02" .

The rest is available at:

http://blogspace.com/rss/example.n3

[1] http://www.w3.org/DesignIssues/Notation3
[2] http://www.w3.org/2000/08/w3c-synd/home.rss
--
Aaron Swartz <me@...>|           my.info
   <http://www.aaronsw.com>   |   <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237|  the future of news, today

Aaron Swartz wrote:
>
> I've put up a new version of the content module:
>
> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.htm
> l

Cool !

I have some more (minor) comments/suggestions...

1) I plan to allow it also in "taxo:topic" elements and I wonder if this
wouldn't make sense in a "channel" element as well.

2) Shouldn't a "content:item" always include a rdf:parse="literal"
attribute ?

3) I think we should list and eventually give more description about the
possible values for the encoding:

Raw XML:
rdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict
Snippet of well formed of XML conform to namespaces in XML 1.0. A good
practice (or should we make it a rule ?) is to include all needed
namespaces declarations to facilitate the task of the the application
that will "cut and paste" the XML elements they will find here.
The content of a content:item/rdf:value is then handled as a XML/XPath
node set including nodes of type elements, text and attributes.

Escaped text:
URL ?
<q>Should we really make it a default value ? We've not used such thing
up to now...</q>
Snippet of text formatted to fit in a XML document (characters "<" and
"&" MUST be escaped, characters ">", """ and "'" MAY be also escaped or
placed with a CDATA section).
The content of a content:item/rdf:value is then handled as a node set
containing only text nodes.

hex:
URL ?
Hex encoded binary field. Can be used to embed anything such as a
(small) picture, a full XML document, a XML snippet that is using
another character encoding, ...

base64:
URL ?
base64 encoded binary field. Can be used to embed anything such as a
(small) picture, a full XML document, a XML snippet that is using
another character encoding, ...

4) Role.

It's a question as much as a suggestion... Do we need anything to
describe the role of the content item ?

Is there a need to include several items with different roles ?

I would tend to add an optional element for this "just in case" since it
would make things much more extensible.

5) Examples

I would include the following items to show the independence between
format and encoding:

<!--HTML-->
<rdf:li>
  <content:item>
   <content:format rdf:resource="http://www.w3.org/TR/html4/" />
   <rdf:value><![CDATA[This is <em>not</em> well formed XML<br>and must
be escaped.]]></rdf:value>
  </content:item>
</rdf:li>
<rdf:li>
  <content:item>
   <content:format rdf:resource="http://www.w3.org/TR/html4/" />
   <content:encoding
rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed" />
   <rdf:value><![CDATA[This HTML <em>is</em> well formed XML and may be
kept as raw XML.]]></rdf:value>
  </content:item>
</rdf:li>
<!-- text -->
<rdf:li>
  <content:item rdf:about="http://example.org/item/content-here.txt">
   <content:format
rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/text/plai\
n"
/>
   <rdf:value>1 < 2</rdf:value>
  </content:item>
</rdf:li>
<rdf:li>
  <content:item rdf:about="http://example.org/item/content-here.txt">
   <content:format
rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/text/plai\
n"
/>
   <rdf:value><![CDATA[(x < 2) && ( y> 3) ]]</rdf:value>
  </content:item>
</rdf:li>
<rdf:li>
  <content:item rdf:about="http://example.org/item/content-here.txt">
   <content:format
rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/text/plai\
n"
/>
   <content:encoding
rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed" />
   <rdf:value>This text is also a well formed XML snippet</rdf:value>
  </content:item>
</rdf:li>

And maybe some examples of hex/base64...

6) notes

And finally, maybe a note to highlight the very different treatment
depending on the encoding for all the tools relying on SAX or DOM
parsers and especially of XSLT transformations.

When the encoding is "raw XML", the full tree of the included content is
available to the tool that can process it easily. When any other
encoding is defined (even escaped text), the tool gets a string that it
cannot easily parse and process...

Hope this helps !

Eric

> I've got a new (valid RDF) syntax, added some of Eric's suggestions, and
> made everything more clear. Here's what the syntax looks like at its
> simplest:
>
> <content:items><rdf:Bag><rdf:li>
>   <content:item rdf:about="http://a.org/content.svg">
>     <content:format rdf:resource="http://www.w3.org/2000/svg" />
>   </content:item>
> </rdf:li></rdf:Bag></content:items>
>
> If there are no objections to it, I think I'll put it up for a poll on
> whether to release it as 1.0.
>
> (Oh, and if anyone else feels their name should go on the spec, please let
> me know. I can't remember everyone who contributed.)
>
> Thanks!
> --
> Aaron Swartz <me@...>|               RSS Info
>   <http://www.aaronsw.com>   |   <http://www.blogspace.com/rss/>
> AIM: JediOfPi | ICQ: 33158237| news and information on the RSS format
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com

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

Great work :-)

Fancy hacking up a new XSLT sheet for W3C that can output N3 alongside
the RSS 1.0 version?

Mmmm, human-readable...

Dan

On Tue, 6 Feb 2001, Aaron Swartz wrote:

> One of the cool things about having RSS as an RDF format (among others) is
> the ability to use it to test out all of the new bleeding-edge RDF tools. On
> the suggestion of DanBri, and thanks to the kind assistance of Sean Palmer,
> I'm proud to present an example RSS file in the Notation3 language[1].
>
> Notation3 is an RDF language designed to be easy to write and read in ASCII
> environments (like email). It's very simple -- to write an RDF triple you
> simply write:
>
> <#subject-uri> <#predicate-uri> <#object-uri> .
>
> (it has namespace prefixes too, of course) It also has a few more
> complicated features like anonymous nodes, etc. but I won't get in to those.
> Anyway, here's the first part of the W3C's RSS file[2] in Notation3:
>
> @prefix : <http://purl.org/rss/1.0/> .
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>
> <http://www.w3.org/2000/08/w3c-synd/home.rss> a channel ;
>   :title "The World Wide Web Consortium" ;
>   :description "Leading the Web to its Full Potential..." ;
>   :link "http://www.w3.org/" ;
>   dc:date "2001-02-06T20:07:40Z" ;
>   :items [ a rdf:Seq;
>     rdf:_1 <http://www.w3.org/Graphics/SVG/Test/>;
>     rdf:_2 <http://www.w3.org/2001/01/WSWS>;
>     rdf:_3 <http://www.w3.org/TR/2001/WD-xml-infoset-20010202/>;
>     rdf:_4 <http://www.w3.org/TR/2001/NOTE-xmldsig-p3p-profile-20010202/>;
>     rdf:_5 <http://www.w3.org/2001/di/Activity> ] .
>
> <http://www.w3.org/Graphics/SVG/Test/> a :item;
>   :title "SVG Test Suite Available";
>   :description
>      """2 February 2001: The W3C Scalable Vector Graphics (SVG)
>      Working Group has published an enhanced and updated version of the SVG
>      Conformance Test Suite, the second public release. The results of
>      testing six implementations against the test suite are also available.
>      SVG is a language for describing two-dimensional vector, image, and
>      text graphics in XML.""" ;
>   :link <http://www.w3.org/Graphics/SVG/Test/>;
>   dc:date "2001-02-02" .
>
> The rest is available at:
>
> http://blogspace.com/rss/example.n3
>
> [1] http://www.w3.org/DesignIssues/Notation3
> [2] http://www.w3.org/2000/08/w3c-synd/home.rss
> --
> Aaron Swartz <me@...>|           my.info
>   <http://www.aaronsw.com>   |   <http://my.theinfo.org>
> AIM: JediOfPi | ICQ: 33158237|  the future of news, today
>
>

Eric van der Vlist <vdv@...> wrote:

>> http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.html
> 1) I plan to allow it also in "taxo:topic" elements and I wonder if this
> wouldn't make sense in a "channel" element as well.

I think this would require the addition of a role element:

> 4) Role.
> It's a question as much as a suggestion... Do we need anything to
> describe the role of the content item ?
>
> Is there a need to include several items with different roles ?
>
> I would tend to add an optional element for this "just in case" since it
> would make things much more extensible.

I'm thinking more along the lines of saving this for version 2. It can
always be added with another module.

> 2) Shouldn't a "content:item" always include a rdf:parse="literal"
> attribute ?

No? What do you mean? That would be sort of silly, wouldn't it?

> 3) I think we should list and eventually give more description about the
> possible values for the encoding:

Yes, I've Jonathan about putting up a RDDL page with this information. I'll
forward your suggestions to him.

> I would include the following items to show the independence between
> format and encoding:

I prefer it the way it is, because:
     a) we show the suggested "best" way to encode each format
     b) pointing to external files is better anyway

> And finally, maybe a note to highlight the very different treatment
> depending on the encoding for all the tools relying on SAX or DOM
> parsers and especially of XSLT transformations.

I think this is totally outside the scope of the module... but if you want
to write something I'll be happy to add it.

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Aaron Swartz wrote:
>
> Eric van der Vlist <vdv@...> wrote:
>
> >>
http://groups.yahoo.com/group/rss-dev/files/Modules/Proposed/mod_content.html
> > 1) I plan to allow it also in "taxo:topic" elements and I wonder if this
> > wouldn't make sense in a "channel" element as well.
>
> I think this would require the addition of a role element:

I need it for XMLfr, though ;=) ...

> > 4) Role.
> > It's a question as much as a suggestion... Do we need anything to
> > describe the role of the content item ?
> >
> > Is there a need to include several items with different roles ?
> >
> > I would tend to add an optional element for this "just in case" since it
> > would make things much more extensible.
>
> I'm thinking more along the lines of saving this for version 2. It can
> always be added with another module.

What do you mean ?

> > 2) Shouldn't a "content:item" always include a rdf:parse="literal"
> > attribute ?
>
> No? What do you mean? That would be sort of silly, wouldn't it?

I don't think so. I saw it in a previous proposal and thought it would
be a good think.

It's kind of equivalent for RDF to what a CDATA section is for XML and,
here, I don't think we want to bother RDF parsers with the structure of
the rich content we are including that shouldn't carry much semantic.

Or have I missed something ?

Eric

> > 3) I think we should list and eventually give more description about the
> > possible values for the encoding:
>
> Yes, I've Jonathan about putting up a RDDL page with this information. I'll
> forward your suggestions to him.
>
> > I would include the following items to show the independence between
> > format and encoding:
>
> I prefer it the way it is, because:
>     a) we show the suggested "best" way to encode each format
>     b) pointing to external files is better anyway
>
> > And finally, maybe a note to highlight the very different treatment
> > depending on the encoding for all the tools relying on SAX or DOM
> > parsers and especially of XSLT transformations.
>
> I think this is totally outside the scope of the module... but if you want
> to write something I'll be happy to add it.
>
> --
> [ Aaron Swartz | me@... | http://www.aaronsw.com ]
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com

--
See you in Austin (Knowledge Technologies 2001)
               http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------

--- In rss-dev@y..., Eric van der Vlist <vdv@d...> wrote:
> eisen@p... wrote:
> >
> > Oh my. I think this is overly complex.
>
> ???
>
> It's the most simple proposal we've done so far except the current
one
> that is not valid RDF !
>
...
> > I'll reiterate my personal need and vision for the taxonomy
module.
>
> My view -if you don't want to call it a vision- is that the taxonomy
> module should be doing what DC subject does with URI identifiers
instead
> of text (sufficient to achieve (1)) and, optionally, give a concise
> description of the topic (needed for (2)).
>
> > I would like to have "What's Related" type links from RSS files.
Yes,
> > it would be nice to have a list; one to a Dmoz directory, one to
> > Yahoo, one to my articles page, and one to one of Rael's
articles. Of
> > course, to do this, I need to categorize the items. I can already
> > sorta do this with dc. But is sure would be nice to have a label
and
> > URL to the category resource.
>
> Yes, it's what the taxonomy module does.
>
> However, the discussion carried so far has shown:
>
> 1) using the dc:subject in place of what I have called "taxo:topics"
> would be confusing since one would have to parse it before telling
if
> it's raw DC or taxo:module.
> ===> taxo:topics
> 2) "people" prefer to avoid multiple elements except within RDF
> containers.
> ===> rdf:Bag/rdf:li
> 3) it is not valid RDF to define a value within a reference to a
> resource, thus, to attach a label to a topic, it is better to
dissociate
> the reference (rdf:li resource=...) from the definition of this
topic.
> ===> rdf:topic.
>
> These choices are not always my preferred ones, I am just seeking a
> consensus and I think this proposal is a fair compromise.
>
> > If I'm off base, perhaps someone can articulate the benefit of the
> > more complex model given that it will be more difficult to
understand
> > and program than what has been proposed previously.
>
> What has been proposed previously is not a valid RDF document and
most
> of the RDF parser are blowing out when reading it.
>
I was not aware this was an issue. I'm willing to support the
proposal compared to the present since it's a step forward. I am
still concerned about the complexity.

--- In rss-dev@y..., Eric van der Vlist <vdv@d...> wrote:
> I have updated the RSS 1.0 feed for XMLfr to implement the new
proposal
> for the taxonomy module:
>
> http://xmlfr.org/actualites/general.rss10
>
> Like for the previous version, the URIs used to identify the topics
can
> be derefenced producing a dynamic page querying rdfDB to get a list
of
> articles relevant for the topic.
>
That looks pretty good.

eisen@... <eisen@...> wrote:

> I'm willing to support the
> proposal compared to the present since it's a step forward. I am
> still concerned about the complexity.

Could you please be more specific about what you feel is complex? I don't
see anything complicated about the current proposal.

Thanks,

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

Before we go for a poll, is there any comments on the proposal
(including updates to be done to the authors list) ?

Thanks

Eric
--
See you in Austin (Knowledge Technologies 2001)
               http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------

Eric van der Vlist <vdv@...> wrote:

> Before we go for a poll, is there any comments on the proposal
> (including updates to be done to the authors list) ?

One, I think the dc: namespace should be removed from the spec and taken out
of the example (it's not part of the module). Two, I think it should be
stated that all elements that can be used in channel (except for items,
textinput, image) can be used in taxo:topic unless stated otherwise.

In the model, you never mention rdf:about and specify taxo:title and
taxo:link, when rss:title and rss:link are used in the example.

Typos:

> First level Element:

Element is not a proper noun and should not be capitalized.

> This element is (optionaly) defining a topic.

Should be: This element is optionally used to define a topic.

> Second level Element (may be included in channel, item or taxo:topic:

Should be: Second level element (may be included in channel, item or
taxo:topic):

> * <taxo:topics> (rdf:Bag/rdf:li)

The model is actually just an rdf:Bag. The model of rdf:Bag is rdf:li.

> This element is (through a rdf:Bag/rdf:li structure) giving a list of topics

Should be: This element gives (using an rdf:Bag/rdf:li structure) a list of
topics

However, I still think this module looks really good.

--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]

In keeping with the suggestions I made at:

http://groups.yahoo.com/group/rss-dev/message/1210

I have updated the RSS Schema and placed my updated version at:

http://logicerror.com/rss-rdf-schema-revised

I made no significant changes to the schema -- I only fixed typos. Rael, if
you could update the version eGroups, that would be great.

Thanks,
--
Aaron Swartz <me@...>|           my.info
   <http://www.aaronsw.com>   |   <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237|  the future of news, today