RSS 1.1

[Sean B. Palmer]

On behalf of an independent group of RSS 1.0 users, I'm pleased to
announce the following specification and toolset for the consideration
of RSS-Dev WG members and interested mailing list participants:

http://inamidst.com/rss1.1/
- RSS 1.1 Specification

RSS 1.1 constitutes a bugfix release of RSS 1.0, and focuses on
evolution along the same path that RSS 1.0 has trod. We have resolved
the numerous bugs that have been noted on the RSS 1.0 Wiki [1], and
incorporated sundry changes that reflect recent developments in both RDF
and syndication thought, as well as other architectural and
internationalization based changes.

We've assembled a range of implementations, including an RSS 1.1 feed
validator; an RSS 1.0 to 1.1, and 1.1 to XHTML converter; a test suite;
and implementations for Movable Type and Wordpress, all of which are
linked to from the following guide:

http://inamidst.com/rss1.1/guide
- A Rough Guide to RSS 1.1

Specific typographical corrections may be sent directly to the editors,
the contact details for whom are in the specification. All other
feedback should be sent by responding to this thread, or by joining the
#rss1.1 channel on the irc.freenode.net IRC network.

Thanks,

[1] http://internetalchemy.org/wiki/RssIssues
--
Sean B. Palmer, http://inamidst.com/sbp/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Chris Croome]

Hi

Fantastic work! Amazing stuff :-)

Who has access to http://purl.org/rss/ -- because I'd support the
setting up of http://purl.org/rss/1.1/ for this ASAP (it's a drag
changing namespaces after they are in widespread use...).

Chris
--
Chris Croome <chris-u/***@public.gmane.org>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Ian Davis]

Post by Chris Croome
Hi
Fantastic work! Amazing stuff :-)
Who has access to http://purl.org/rss/ -- because I'd support the
setting up of http://purl.org/rss/1.1/ for this ASAP (it's a drag
changing namespaces after they are in widespread use...).

I can do this but I'm cautious about doing it yet. Perhaps something
more explicit such as http://purl.org/rss/1.1DRAFT/ would be better in
the meantime?

Ian



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Post by Ian Davis

I'd support the setting up of http://purl.org/rss/1.1/ for this
[...]

I can do this but I'm cautious about doing it yet. Perhaps something
more explicit such as http://purl.org/rss/1.1DRAFT/ would be better
in the meantime?

Prior to the release of the draft, this was a big concern for us. As
I've already stated to David Megginson on xml-dev [1], we wanted the
draft to be in an implementation-ready state at announcement time. We
decided that since RSS-Dev WG business must be conducted in public, per
the process document [2], private application for the namespace was out
of the question, and thus went with our current namespace.

Should the uptake of RSS 1.1 have been initially very slow, we could
have still made this relatively major change, but since we're seeing a
number of aggregators being upgraded to support it and feeds being
produced, it's already too late from an implementation standpoint.

The negative impact is negligible: tools treat namespace URIs opaquely,
and so this is purely a socio-political issue. Maintaining the same
lineage as the RSS 1.0 namespace is only preferable for aesthetic
reasons, and to let people know that it's likely that the same group is
responsible for both languages. But the former isn't too important (I'm
pleased with "/net/rss1.1#"), and the latter can also be achieved by
simply having the RSS-Dev WG ratify RSS 1.1 as the chosen evolutionary
path--as Danbri puts it. But I'll save that for the other thread.

We certainly appreciate the offer of the 1.1DRAFT namespace, but again
this would mean at least two more namespace changes, which we're really
looking to avoid. I think that the popularity of the ^ns namespace
lookup feature on Chris's redlandbot [3] proves that people are most
inclined to cut and paste namespaces anyway rather than memorising them
all. The RDF namespace itself is particularly horrible.

Thanks again for the offer,

[1] http://lists.xml.org/archives/xml-dev/200501/msg00409.html
[2] <http://f5.grp.yahoofs.com/v1/0FnuQU3aaCKj-H9kUuxJiWE5AlkA
qhy7MPfccQKd1IFRPpmAwQcMSjFYj8kynkaag0gPAee3mtG7trJPG-ZgV
8nlG3D8bpxL9oj2/RSS-DEV%20Policies%20and%20Procedures>
[3] http://crschmidt.net/redlandbot/
--
Sean B. Palmer, http://inamidst.com/sbp/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[m***@public.gmane.org]

Post by Ian Davis
I can do this but I'm cautious about doing it yet. Perhaps
something more explicit such as http://purl.org/rss/1.1DRAFT/
would be better in the meantime?

I agree. Perhaps now's the time to call for a vote among the rss-dev
committee members on it?

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by m***@public.gmane.org

Post by Ian Davis
I can do this but I'm cautious about doing it yet. Perhaps
something more explicit such as http://purl.org/rss/1.1DRAFT/
would be better in the meantime?

I agree. Perhaps now's the time to call for a vote among the rss-dev
committee members on it?

I guess asking this now would mix up following questions:
- is an update needed?
- is a change to version 1.1 with a change of namespace needed?
- is Sean's and Christopher's proposal a good starting point?
- Is a NoDerivs-license usable for a community process?

reto



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

Post by Reto Bachmann-Gmuer

Post by m***@public.gmane.org

Post by Ian Davis
I can do this but I'm cautious about doing it yet. Perhaps
something more explicit such as http://purl.org/rss/1.1DRAFT/
would be better in the meantime?

I agree. Perhaps now's the time to call for a vote among the rss-dev
committee members on it?

- is an update needed?

I think that this is a question that can be answered simply by looking
over the history of RSS 1.0. There have been a number of evolutions in
both RDF and syndication since the RSS 1.0 specification was released,
which can be used to the advantage of the format.

Post by Reto Bachmann-Gmuer
- is a change to version 1.1 with a change of namespace needed?

This question is far more up to debate in my opinion. The motivations
behind this change haven't been very clearly explained (or at least not
so clearly as some of our other motivations), so let me outline why this
actually happened:

When we first started playing around with the idea of creating a
specification like the one we released, we tested a series of changes in
a bunch of different tools, in order to determine what would work and
what wouldn't. What we found out is that it doesn't take changing much
in order to break backwards compatibility in most tools: they're very
specific to the exact XML format of RSS 1.0, and to ensure that the
format be entirely backwards compatible would have required such
marginal changes as to be almost completely useless.

When we realized that it was going to be practically impossible to
achieve anything worthwhile with a 100% backwards compatibility line, we
decided for a time to take a completely revolutionary approach: forget
RSS 1.0, make a new RDF based syndication format. No more <link> as a
literal: make it an rdf:resource! Change everything about RSS 1.0 that
makes it an XML syndication format: it was built as RDF, it should be
consumed as RDF. When we looked at it, however, we realized we were
heading the way that Atom had gone. If a lot of really smart people have
taken as much time as they have to create a syndication format that
makes people happy, why would we be able to do better?

So, backwards compatibility was out. Complete revolution was out.
Instead, we chose to walk a very thin line between the two: trying to
fix bugs in RSS 1.0 while creating a specification that would have
minimal impact on implementors, both producers and consumers.

I hope that we have succeeded, and changes to some aggregators and
comments from the authors of such have made it seem that way to me. I
know that I personally have looked into patching a couple of aggregation
tools (XML::RSS and MagpieRSS) and neither one required more than a
dozen lines of changes in code to consume RSS 1.1 properly. So, my
experience seems to indicate that we did achieve that goal, at least to
some extent.

Post by Reto Bachmann-Gmuer
- is Sean's and Christopher's proposal a good starting point?

I think so, but I'm biased ;)

Post by Reto Bachmann-Gmuer
- Is a NoDerivs-license usable for a community process?

The NoDerivs license covers only the prose of the Specification: the
format itself is not under any license, and can be freely used by
anyone. If someone wished to evolve the format further, they would
certainly be free to, as the Status section outlines.

I certainly don't think this is a major blocker for evolution of the
format: RSS 1.1, for example, takes no prose from the RSS 1.0
specification, so I don't understand why further evolution would need a
more permissive license than the ND allows.

I hope I've addressed the concerns you've raised. I understand that in
some cases, the answers I have aren't what you want to hear, but I've
explained my thoughts on your concerns the best I can.

Thanks again,
--
Christopher Schmidt



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- is an update needed?

I think that this is a question that can be answered simply by looking
over the history of RSS 1.0. There have been a number of evolutions in
both RDF and syndication since the RSS 1.0 specification was released,
which can be used to the advantage of the format.

A good point. However the only use of newer RDF features I can see is in
the payload module not in the core. You do use new RDF/XML features:
-parseType="Resource": nice!
-parseType="Collection": good,but doesn't solve the problems with items
-omit rdf:RDF: makes it impossible to add arbitrary triples to the
RSS-Document

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- is a change to version 1.1 with a change of namespace needed?

This question is far more up to debate in my opinion. The motivations
behind this change haven't been very clearly explained (or at least not
so clearly as some of our other motivations), so let me outline why this
When we first started playing around with the idea of creating a
specification like the one we released, we tested a series of changes in
a bunch of different tools, in order to determine what would work and
what wouldn't. What we found out is that it doesn't take changing much
in order to break backwards compatibility in most tools: they're very
specific to the exact XML format of RSS 1.0, and to ensure that the
format be entirely backwards compatible would have required such
marginal changes as to be almost completely useless.
When we realized that it was going to be practically impossible to
achieve anything worthwhile with a 100% backwards compatibility line, we
decided for a time to take a completely revolutionary approach: forget
RSS 1.0, make a new RDF based syndication format. No more <link> as a
literal: make it an rdf:resource! Change everything about RSS 1.0 that
makes it an XML syndication format: it was built as RDF, it should be
consumed as RDF. When we looked at it, however, we realized we were
heading the way that Atom had gone. If a lot of really smart people have
taken as much time as they have to create a syndication format that
makes people happy, why would we be able to do better?
So, backwards compatibility was out. Complete revolution was out.
Instead, we chose to walk a very thin line between the two: trying to
fix bugs in RSS 1.0 while creating a specification that would have
minimal impact on implementors, both producers and consumers.
I hope that we have succeeded, and changes to some aggregators and
comments from the authors of such have made it seem that way to me. I
know that I personally have looked into patching a couple of aggregation
tools (XML::RSS and MagpieRSS) and neither one required more than a
dozen lines of changes in code to consume RSS 1.1 properly. So, my
experience seems to indicate that we did achieve that goal, at least to
some extent.

So you gave up backward compatibility in an attempt to be revolutionary.
Now you postponed revolution and that's the time to reconsider
compatibility. I think the ability to deprecate properties is a nice
feature and renders -in this case - a new namespace obsolete. on
http://esw.w3.org/topic/RSS I've fixed the RSS bugs my way, but you
could go much closer to the model you propose, the only exception is the
image property, where I don't think it's possible to deprecate its class
usage but not its property usage.

We'll its hard to be compatible on a xml-level when dropping the rdf:RDF
root element, but as I said I doubt this is a good idea anyway.

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- is Sean's and Christopher's proposal a good starting point?

I think so, but I'm biased ;)

:-)

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- Is a NoDerivs-license usable for a community process?

The NoDerivs license covers only the prose of the Specification: the
format itself is not under any license, and can be freely used by
anyone. If someone wished to evolve the format further, they would
certainly be free to, as the Status section outlines.
I certainly don't think this is a major blocker for evolution of the
format: RSS 1.1, for example, takes no prose from the RSS 1.0
specification, so I don't understand why further evolution would need a
more permissive license than the ND allows.

Take my experiments on a backward compatible evolution, I've considered
editing your document, I saw the license so I took the 1.0 spec. What's
your motivation for "NoDerivs", "it doesn't seem to harm to much"
doesn't convince me.

reto



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

Post by Reto Bachmann-Gmuer

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- is an update needed?

I think that this is a question that can be answered simply by looking
over the history of RSS 1.0. There have been a number of evolutions in
both RDF and syndication since the RSS 1.0 specification was released,
which can be used to the advantage of the format.

A good point. However the only use of newer RDF features I can see is in
-parseType="Collection": good,but doesn't solve the problems with items

I'm not sure what you mean by this: what problems with items? It creates
an ordered list in RDF, but at the same time doesn't generate (much)
syntactic cruft for tools which don't understand RDF. (Most aggregators
that I've found do not use RDF to parse these files.)

Post by Reto Bachmann-Gmuer
-omit rdf:RDF: makes it impossible to add arbitrary triples to the
RSS-Document

Since no source is going to want to aggregate these "arbitrary triples"
anyway, why would allowing them make any sense?

Post by Reto Bachmann-Gmuer
So you gave up backward compatibility in an attempt to be revolutionary.
Now you postponed revolution and that's the time to reconsider
compatibility. I think the ability to deprecate properties is a nice
feature and renders -in this case - a new namespace obsolete. on
http://esw.w3.org/topic/RSS I've fixed the RSS bugs my way, but you
could go much closer to the model you propose, the only exception is the
image property, where I don't think it's possible to deprecate its class
usage but not its property usage.

Using the same RSS 1.0 namespace is, quite simply, broken. The namespace
uses image as both a property and a class, which is prohibited by the
OWL specifications. Using it is broken. However, the next draft of the
RSS1.1 spec (which will be released tomorrow) will have informative
mappings in OWL from RSS 1.0 to RSS 1.1, so tools which understand OWL
will be able to understand the changes from RSS 1.0 to RSS 1.1.

Looking at the page on the ESW wiki:

The first example does not have any ordering in the items, as far as RDF
goes. There is no way to know what is the actual order, in RDF. This
order is the entire reason behind the rdf:parseType="Collection" in the
first place, and was also the reason behind the rdf:Seq. From an XML
point of view, the "inChannel" aspect is far more extra syntactic cruft
than the parseType="Collection" would be.

Not only that, but as you say, this format doesn't work in old
aggregators, so you're not keeping backwards compatibility.

1. Breaking compatibility
2. Loss of ordering of items
3. Extra cruft via "inChannel"

Your second example still contains the only thing I really wanted to get
rid of with 1.1, the rdf:Seq element. I think that this aspect of RSS
1.0 is the primary one which would cause content creators to "pass it
by" for something simpler, so bringing that back is not an option I'm in
favor of.

I understand the desire to keep backwards compatibility, but both of
these examples demonstrate problems in the way they're done: one with no
order in the RDF, the second with the rdf:Seq that has always been a pet
peeve with the specification.

I'm open to discussion on this, of course, and if the will of the
community was against 1.1 as is, and towards something different, I'm
sure that will be shown as time passes, but the problems I've outlined
are the exact reasons why RSS 1.1 didn't go the way that you've suggested
in the first place.

Regards,
--
Christopher Schmidt




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[David Galbraith]

What are the things that RSS 1.1 solves that people have been asking
for?

The reality is that RSS is a mess, the problem is not utility but
confusion over too many names. RSS 2.0 has won mindshare, the technical
details of the standard are almost irrelevant. RSS 1.0 has some benefits
in some instances, but a much better focus for this group would be on
modules.

5 years later, new RSS modules are not read by a single aggregator and
there is no process or tools for building modules.

If 1.1 is not backwards compatible to 1.0, then 1.1 is poss. a
misleading name and it can't be called 2.0 etc.
Without backwards compatibility there is now yet another standalone
flavor of RSS/Atom, so the practical, end user benefits of the new
standard have to outweigh the drawbacks of confusion.

Post by Reto Bachmann-Gmuer

Post by Christopher Schmidt
There have been a number of evolutions in
both RDF and syndication since the RSS 1.0 specification was

released,

Post by Reto Bachmann-Gmuer

Post by Christopher Schmidt
which can be used to the advantage of the format."

If evolutions in RDF and Syndication allow for a new standard with much
better features that people users proactively asking for, then they
should be measured against the downside of yet more confusion amongst
users.



-----Original Message-----
From: Christopher Schmidt [mailto:crschmidt-ShfR2DvLQHoeIZ0/***@public.gmane.org]
Sent: Sunday, January 23, 2005 8:58 AM
To: rss-dev-***@public.gmane.org
Subject: Re: Setting up a purl for rss/1.1, was: Re: [RSS-DEV] RSS 1.1

Post by Reto Bachmann-Gmuer

Post by Christopher Schmidt

Post by Reto Bachmann-Gmuer
- is an update needed?

I think that this is a question that can be answered simply by looking
over the history of RSS 1.0. There have been a number of evolutions in
both RDF and syndication since the RSS 1.0 specification was

released,

Post by Reto Bachmann-Gmuer

Post by Christopher Schmidt
which can be used to the advantage of the format.

A good point. However the only use of newer RDF features I can see is in
-parseType="Collection": good,but doesn't solve the problems with items

I'm not sure what you mean by this: what problems with items? It creates

an ordered list in RDF, but at the same time doesn't generate (much)
syntactic cruft for tools which don't understand RDF. (Most aggregators
that I've found do not use RDF to parse these files.)

Post by Reto Bachmann-Gmuer
-omit rdf:RDF: makes it impossible to add arbitrary triples to the
RSS-Document

Since no source is going to want to aggregate these "arbitrary triples"
anyway, why would allowing them make any sense?

Post by Reto Bachmann-Gmuer
So you gave up backward compatibility in an attempt to be

revolutionary.

Post by Reto Bachmann-Gmuer
Now you postponed revolution and that's the time to reconsider
compatibility. I think the ability to deprecate properties is a nice
feature and renders -in this case - a new namespace obsolete. on
http://esw.w3.org/topic/RSS I've fixed the RSS bugs my way, but you
could go much closer to the model you propose, the only exception is the
image property, where I don't think it's possible to deprecate its class
usage but not its property usage.

Using the same RSS 1.0 namespace is, quite simply, broken. The namespace

uses image as both a property and a class, which is prohibited by the
OWL specifications. Using it is broken. However, the next draft of the
RSS1.1 spec (which will be released tomorrow) will have informative
mappings in OWL from RSS 1.0 to RSS 1.1, so tools which understand OWL
will be able to understand the changes from RSS 1.0 to RSS 1.1.

Looking at the page on the ESW wiki:

The first example does not have any ordering in the items, as far as RDF

goes. There is no way to know what is the actual order, in RDF. This
order is the entire reason behind the rdf:parseType="Collection" in the
first place, and was also the reason behind the rdf:Seq. From an XML
point of view, the "inChannel" aspect is far more extra syntactic cruft
than the parseType="Collection" would be.

Not only that, but as you say, this format doesn't work in old
aggregators, so you're not keeping backwards compatibility.

1. Breaking compatibility
2. Loss of ordering of items
3. Extra cruft via "inChannel"

Your second example still contains the only thing I really wanted to get

rid of with 1.1, the rdf:Seq element. I think that this aspect of RSS
1.0 is the primary one which would cause content creators to "pass it
by" for something simpler, so bringing that back is not an option I'm in

favor of.

I understand the desire to keep backwards compatibility, but both of
these examples demonstrate problems in the way they're done: one with no

order in the RDF, the second with the rdf:Seq that has always been a pet

peeve with the specification.

I'm open to discussion on this, of course, and if the will of the
community was against 1.1 as is, and towards something different, I'm
sure that will be shown as time passes, but the problems I've outlined
are the exact reasons why RSS 1.1 didn't go the way that you've
suggested
in the first place.

Regards,
--
Christopher Schmidt




Yahoo! Groups Links










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

comprehensive response, thanks Christopher! - let me split the reply

Post by Christopher Schmidt
I'm not sure what you mean by this: what problems with items? It creates
an ordered list in RDF, but at the same time doesn't generate (much)
syntactic cruft for tools which don't understand RDF. (Most aggregators
that I've found do not use RDF to parse these files.)

When you join the RDF-models of two versions of a feed you a channel
with two "items" properties which refer to partially the same "Item"s.
In the resulting model you have no way to determine which Seq or
Collection is the newer one.

Well RSS-Aggregators are not just aggregating models and analysing the
broken result. But true compatibility with generic RDF aggregators and
the ability to use RSS-terms describing more complex information
resources than just a single language channel at one moment in time is
where the strength of RSS 1.x come into play. RDF is the raison d'être
of this branch and should not be compromised in order to compete with
other syndication formats in terms of easy XML.

reto



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Christopher Schmidt
Using the same RSS 1.0 namespace is, quite simply, broken. The namespace
uses image as both a property and a class, which is prohibited by the
OWL specifications.

It is legal in RDF/RDFS and in owl-full. RSS-documents that do not use
the image as class are also legal in OWL Lite and OWL DL. Deprecating
image is fine, but there is no need to drop the namespace.

reto




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Christopher Schmidt
The first example does not have any ordering in the items, as far as
RDF goes. There is no way to know what is the actual order, in RDF.
This order is the entire reason behind the rdf:parseType="Collection"
in the first place, and was also the reason behind the rdf:Seq. From
an XML point of view, the "inChannel" aspect is far more extra
syntactic cruft than the parseType="Collection" would be.

The items are sorted by releaseDate by default since this is how rss is
used in most cases, but it it possible to define alternative sorting
orders by the use of extension modules. I've fixed the wrong description
of the releaseDate property.

Post by Christopher Schmidt
Not only that, but as you say, this format doesn't work in old
aggregators, so you're not keeping backwards compatibility.
1. Breaking compatibility

The first compact example is not compatible, but more compact than its
counterpart following the previous spec. Chances that it happens to be
understood by a poorly programmed aggregator are a bit better than with
your proposal. But that's not my point, the second examples uses
deprecated property to be compatible with old aggregators while
containing every triple a new parse expects. This allows a smooth
transition, without having just one more format.

Post by Christopher Schmidt
2. Loss of ordering of items

I've mentioned a module to sort triples in an other order than by
release-date on
http://lists.w3.org/Archives/Public/www-rdf-interest/2005Jan/0183.html,

The following property of channel could be used to sort the elements by
the value of another property

<rss-sort:sortAscending
rdf:resource="http://eample.org/ontogies/events#EventDate" />

Of course a module could also define a "collection" or seq-based
ordering, but I don't think such a module would be widely adopted.

Post by Christopher Schmidt
3. Extra cruft via "inChannel"
Your second example still contains the only thing I really wanted to
get rid of with 1.1, the rdf:Seq element. I think that this aspect of
RSS 1.0 is the primary one which would cause content creators to
"pass it by" for something simpler, so bringing that back is not an
option I'm in favor of.

The second example contains deprecated statements to be compatible with
old aggregators, newer aggregator should ignore the deprecated stuff.
It's not possible to be compatible without "items", but it is left to
the producer to make feed compatible or smaller and cleaner.

Post by Christopher Schmidt
I understand the desire to keep backwards compatibility, but both of
these examples demonstrate problems in the way they're done: one
with no order in the RDF, the second with the rdf:Seq that has always
been a pet peeve with the specification.

I don't see that much difference between the "collections" and seq. But
the problem is "items".

Post by Christopher Schmidt
I'm open to discussion on this, (...)

me too ;-)

reto




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Ken MacLeod]

Post by Reto Bachmann-Gmuer

Post by Reto Bachmann-Gmuer
- Is a NoDerivs-license usable for a community process?

the format itself is not under any license, and can be freely used
by anyone. If someone wished to evolve the format further, they
would certainly be free to, as the Status section outlines.
I certainly don't think this is a major blocker for evolution of
the format: RSS 1.1, for example, takes no prose from the RSS 1.0
specification, so I don't understand why further evolution would
need a more permissive license than the ND allows.

Take my experiments on a backward compatible evolution, I've
considered editing your document, I saw the license so I took the
1.0 spec. What's your motivation for "NoDerivs", "it doesn't seem to
harm to much" doesn't convince me.

You are technically correct, but possibly misunderstanding intent.

All spec development organizations use "no derivation" licenses. That
means that once a specification is generated, it must follow that
organization's policies for future development. Any member may
produce a proposal or draft against that spec for presentation as a
successor, according to the organization's policies.

So the issue here is not the "no derivation" license, but the
ownership of the copyright. It is correct to say that only Sean and
Christopher may update their proposal, as currently copyrighted and
licensed.

However, I don't think that that is their intent.

Several possibilities exist. If the RSS-DEV WG chooses to adopt the
proposal (and so far I'm personally open to this), then the copyright
could be assigned to the group and follow the group's policies.
Possibly better in any case would be to have the spec hosted by the W3
as a Note as part of the Semantic Web Activity (I don't think
vocabularies should go the Rec route), assigning the copyright to the
W3.

-- Ken



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[m***@public.gmane.org]

Post by Ken MacLeod
Several possibilities exist. If the RSS-DEV WG chooses to
adopt the proposal (and so far I'm personally open to this),
then the copyright could be assigned to the group and follow
the group's policies.

As another WG member I likewise would be willing to consider the proposal
and move toward encouraging it's use.

Post by Ken MacLeod
Possibly better in any case would be to have the spec hosted
by the W3 as a Note as part of the Semantic Web Activity (I
don't think vocabularies should go the Rec route), assigning
the copyright to the W3.

I'm less inclined to support this notion if only to avoid adding yet another
layer to the process. It's not a 'bad idea' but not necessarily one that's
all that necessary IMHO.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Ian Graham]

Post by m***@public.gmane.org

Post by Ken MacLeod
Possibly better in any case would be to have the spec hosted
by the W3 as a Note as part of the Semantic Web Activity (I
don't think vocabularies should go the Rec route), assigning
the copyright to the W3.

I'm less inclined to support this notion if only to avoid adding yet another
layer to the process. It's not a 'bad idea' but not necessarily one that's
all that necessary IMHO.
-Bill Kearney

Submitting it as a W3C note might be helpful to communicate the work and
ideas -- but it doesn't do much beyond that.
--
Ian Graham
H: 416.769.2422 / W: 416.513.5656 / E: <ian . graham AT utoronto . ca>



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

Post by m***@public.gmane.org

Post by Ian Davis
I can do this but I'm cautious about doing it yet. Perhaps
something more explicit such as http://purl.org/rss/1.1DRAFT/
would be better in the meantime?

I agree. Perhaps now's the time to call for a vote among the rss-dev
committee members on it?

Sean already outlined the reasons that he and I are looking to avoid
changing the namespace at this point in another rss-dev message[1]. Due
to the way that implementation has proceeded, there is a relatively
large motivation against changing the namespace two more times in this
process.

If the working group does wish to set up the PURL URI as a namespace,
we will graciously accept it as an additional redirect to the
specification, but the namespace URI defined in the specification will
most likely not be changing.

I appreciate the enthusiasm, and I'm sorry that there isn't more we can
do to accomodate such a change. I believe I've seen enough thoughts on
backwards compatibility that neither I nor Sean want to make things any more
difficult than many people believe they already are.

Thanks again,

[1] http://groups.yahoo.com/group/rss-dev/message/6932
--
Christopher Schmidt



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Hammond, Tony]

Hi Sean:

Couple quick comments on 1.1 before brighter young minds offer their more
studied feedback.

1. The one thing that really sticks out for me is the (rather silly?)
capitalization on the 'Channel' element which looks like a throwback to the
striping model. I think this is 100% guaranteed to put folks off this
format. Let's have striping on - or off. But not some weird hybrid. Nobody,
but nobody (well, maybe some people), will figure out the logic for
uppercasing/lowercasing. Prefer the KISS principle. I do remain vehemently
(sorry, but honest) opposed to this.

2. Some comments on wording.

Abstract has 'popular RSS 1.0'. 2. Motivation has demoted this to 'however,
uptake for RSS 1.0 has been relatively limited'. Do we need to decide?

Abstract has 'RSS 1.1. is as extensible as RSS 1.0 and can even make use of
its extension modules.' All sounds a bit desperate to me.

1. Introduction has 'It allows content distributors such as news portals,
webloggers, and other providers of up-to-the-minute content to publish ...'.
We would argue that RSS 1.0 (and by extension 1.1 ;) is not just for
'up-to-the minute' syndication but represents a generic format for
distributing content using a specific RDF profile. Specifically we (and
possibly other publishers) are interested in providing archival material
with an RSS (read RDF) interface.

2. Motivation. 'RSS 0.92, RSS 2.0, and Atom'. Is that right? - I don't know.
Is '0.92' more successful than '0.91'?

2. Motivation. 'however, uptake for RSS 1.0 has been relatively limited'.
Again true? How limited is 'relatively'?

2. Motivation. 'developing the other descendant of RSS 1.0, Atom'. Excuse
me. I wasn't aware that Atom, as such, was a descendant of RSS 1.0.

3. Just a minor point. The <url> element. Why? Shouldn't this be, at least,
<uri>. (The term URL is pretty much deprectaed these days. Just lingers on
in folksonomies.) The XSD datatype anyuway is 'xsd:anyURI'.

Anyhows, look forward to taking a closer look.

Yours, vehemently opposed, etc.

Tony


Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK

tel:[phone]

-----Original Message-----
Sent: 18 January 2005 14:00
Subject: [RSS-DEV] RSS 1.1
On behalf of an independent group of RSS 1.0 users, I'm
pleased to announce the following specification and toolset
for the consideration of RSS-Dev WG members and interested
http://inamidst.com/rss1.1/
- RSS 1.1 Specification
RSS 1.1 constitutes a bugfix release of RSS 1.0, and focuses
on evolution along the same path that RSS 1.0 has trod. We
have resolved the numerous bugs that have been noted on the
RSS 1.0 Wiki [1], and incorporated sundry changes that
reflect recent developments in both RDF and syndication
thought, as well as other architectural and
internationalization based changes.
We've assembled a range of implementations, including an RSS
1.1 feed validator; an RSS 1.0 to 1.1, and 1.1 to XHTML
converter; a test suite; and implementations for Movable Type
http://inamidst.com/rss1.1/guide
- A Rough Guide to RSS 1.1
Specific typographical corrections may be sent directly to
the editors, the contact details for whom are in the
specification. All other feedback should be sent by
responding to this thread, or by joining the #rss1.1 channel
on the irc.freenode.net IRC network.
Thanks,
[1] http://internetalchemy.org/wiki/RssIssues
--
Sean B. Palmer, http://inamidst.com/sbp/
Yahoo! Groups Links

********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with
registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Dan Brickley]

Post by Hammond, Tony
Couple quick comments on 1.1 before brighter young minds offer their more
studied feedback.
1. The one thing that really sticks out for me is the (rather silly?)
capitalization on the 'Channel' element which looks like a throwback to the
striping model. I think this is 100% guaranteed to put folks off this
format. Let's have striping on - or off. But not some weird hybrid. Nobody,
but nobody (well, maybe some people), will figure out the logic for
uppercasing/lowercasing. Prefer the KISS principle. I do remain vehemently
(sorry, but honest) opposed to this.

I don't think this is silly at all. Capitalisation of class names in RDF
is one of the few hints/heuristics we have to offer folk who don't have
built-in mental RDF parsers. RSS1 was unconventional in that the class
'rss1:channel' was named with a lower-case letter. Most other RDF
vocabs (well, those in the roman alphabet anyway) have classes named
with a capital letter, and properties named with an initial lowercase.
When this convention is used, it makes it relatively easy to skim an RDF
document (even if using unstriped conventions such as
parseType="Resource") since you can generally say to yourself "oh, it's
capitalised... that means that this element stands for an instance of
some class". In FOAF for example we have Person, Document, Image, etc.,
for classes, and everything else is a property. Some programming
languages (eg. Java but not I think C#) stick to similar conventions.

When you see a capital letter, eg. as in the 'C' in

<Channel xmlns="http://purl.org/net/rss1.1#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
rdf:about="http://www.xml.com/xml/news.rss">
<title>XML.com</title>
<link>http://xml.com/pub</link>

...try reading it as "there is a '[C]hannel' and it has a 'title'
property whose value is 'XML.com' and it has a link property whose
value is 'http://xml.com/pub'.

In fact it looks like 'item' ought to be 'Item', for consistency
here, since it is the name of a class...
Looking at the ontology at the end of
http://inamidst.com/rss1.1/ it says:

[[
:items rdf:type rdf:Property;
rdfs:label "items" .

:Items rdf:type owl:Class;
rdfs:label "Items";
rdfs:comment "Never syntactically appears as an element.";
rdfs:subClassOf rdf:List,
[ rdf:type owl:Restriction;
owl:onProperty rdfs:member; owl:allValuesFrom :item ] .

:item rdf:type owl:Class;
rdfs:label "item" .
]]

My preference would be for "items" to be called "ItemList"
with allValuesFrom a class called "Item".

cheers,

Dan



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Post by Hammond, Tony
1. The one thing that really sticks out for me is the (rather silly?)
capitalization on the 'Channel' element which looks like a

The one thing that really sticks out for me is that they had the sense to
capitalise the Channel element. YMMV.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Post by Jon Hanna

Post by Hammond, Tony
1. The one thing that really sticks out for me is the (rather silly?)
capitalization on the 'Channel' element which looks like a

The one thing that really sticks out for me is that they had the sense to
capitalise the Channel element. YMMV.

Heh. I'm with Dan on this one - RDF/XML is easier to read with the
Class/property convention. (Or following the CDF precedent, all
elements shouting ;-)

Generally, this does seem like a pretty reasonable improvement over
1.0, but - this should have been RSS 2.0!

I anticipated 1.0.1/1.1 to be max-compatibility bugfix only, so this
this version came as a bit of a surprise. It doesn't seem to have
direct compatibility beyond being RDF & XML. I won't try to speculate
what this means in the world at large...

I'm not sure about the containment business. I don't think the
justification of syntax similarity to RSS 0.9x/2.0 really counts for
much. What's needed IMHO is the expression that *all* the items from
all feed documents from that URI are in the same container or
collection. I don't think having lots of 15-item Collections will help
(I hope to be proved wrong). Personally I'd probably have got rid of
<items> altogether, and added a <inChannel> property to each item. If
order's needed (is it?), make it explicit with <previous>.

I'd also have the channel URI as the feed rather than feed or homepage.

What might well be useful are normative mappings from/to Atom, RSS 1.0
and RSS 2.0.

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[ecomputerd]

Post by Danny Ayers
I anticipated 1.0.1/1.1 to be max-compatibility bugfix only, so this
this version came as a bit of a surprise. It doesn't seem to have
direct compatibility beyond being RDF & XML. I won't try to

speculate

Post by Danny Ayers
what this means in the world at large...
Cheers,
Danny.

What this means is that we are rapidly approaching the HTML-ization
of RSS Feeds. To write an aggregator, you currently have to parse--
is it 9?--different feed types. Each of the types has different
definitions of their elements. In practice, this means having an
internal list of fields from which to grab the data you display. For
example, to get the actual message you grab either "text"
or "dc:content".

I may be wrong, but each different group appears to be creating
different specifications: this RSS 1.1 group and the Yahoo rss-media
group and the Atom group. These are just the ones *I* know about off
the top of my head. I am not really sure if this is how "standards"
are normally developed or even what a better way would be, besides
everyone joining forces. Personally, I can see the case for Atom
(standardizing blog *posting*) and rss-media (enabling much greater
specification of meta data).

What would be great is a definition of a superset of each of these
efforts. Is that what RSS 1.1 is? Maybe I missed that.

The best process seems (to me) to be Yahoo's rss-media effort
http://groups.yahoo.com/group/rss-media/

There, they are providing samples, asking for commentary, and really
focusing on the *use cases* of the specification. The leader is
making statements/summaries like:

5. Bittorrent. Do we want to explicity note the difference
of "transport" vs. content type? Does it really matter in the end if
we create media groupings? ("application/x-bittorrent;
enclosed=audio/mpeg")

The rss-media approach seems to be super-focused on how to provide a
better experience for users/clients and producers/servers as well as
expanding capability for online aggregators.

Just my take on it.

Greg Smith
Author, FeederReader - The Pocket PC RSS reader and podcatcher
www.FeederReader.com










Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

On Wed, Jan 19, 2005 at 12:47:25PM +0100, Danny Ayers wrote:

Short on time at the moment (doing a day job), but I will respond to one

Post by Danny Ayers
What might well be useful are normative mappings from/to Atom, RSS 1.0
and RSS 2.0.

In the Guide [1], there is an included XSLT to convert from RSS 1.0 to
1.1. Atom is still under discussion, and outside my area of expertise,
so I was not particularly inclined to create a mapping from Atom. If
such a mapping is desired, I'd be glad to work with any in the Atom
community who feel they understand the specification to provide the most
accurate mapping possible.

It may be beneficial to wait until Atom has finished it's current draft
run? Or is .3 widely used enough that implementing a mapping is useful?
--
Christopher Schmidt


[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

On Wed, 19 Jan 2005 09:43:50 -0500, Christopher Schmidt

Post by Christopher Schmidt
It may be beneficial to wait until Atom has finished it's current draft
run? Or is .3 widely used enough that implementing a mapping is useful?

The only thing that's certain is that 0.3 will not be the final
version! If I read things right, this version will be strongly
deprecated once 1.0 comes out.

The Atom WG charter has format spec last call in March, final in April
(same for the protocol/API, btw). Right now if I had any live systems
I'd probably hold off changing until Atom 1.0, but would try and work
from the current spec draft for offline development (see [1]).

Note that material under discussion right now is likely to impact any
mapping - the existing extensibility-related proposals are all in
focus on the issue list [2], and the chair has called "last orders" on
this facet, the result being two new proposals appearing in the past
few days: AtomAsRDF [3] (what it says) and PaceExtensionConstruct [4]
which offers a more general purpose structural interpretation, though
was also prompted by a desire for RDF compatibility.

Cheers,
Danny.

[1] http://ietf.levkowetz.com/drafts/atompub/format/
[2] http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
[3] http://www.intertwingly.net/wiki/pie/AtomAsRDF
[4] http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct


Cheers,
Danny.

[Sean B. Palmer]

Post by Hammond, Tony
1. The one thing that really sticks out for me is the (rather silly?)
capitalization on the 'Channel' element

[I'll reply to this in another thread.]

Post by Hammond, Tony
Abstract has 'popular RSS 1.0'. 2. Motivation has demoted this to
'however, uptake for RSS 1.0 has been relatively limited'. Do we need
to decide?

It's popular but could've been better. Obviously we don't want to set
out to underemphasize RSS 1.0's achievements, which would have been an
easy trap to fall into given that we're seeking to phase it out, but at
the same time we feel that RSS 1.1 is a significant step forward and
need to convey that in the motivation.

We'd certainly be happy to entertain alternative suggestions, however,
if you would like to propose some concrete text.

Post by Hammond, Tony
Abstract has 'RSS 1.1. is as extensible as RSS 1.0 and can even make
use of its extension modules.' All sounds a bit desperate to me.

Desperate in which way? When people read about RSS 1.1 for the first
time, they're going to be in tabula rasa mode, which is to say that they
don't know a single thing about the format. The easiest way to explain
its nature is to compare it feature-by-feature with other formats--RSS
1.0 being the obvious choice for such comparisons.

If I were an RSS 1.0 user coming across RSS 1.1 for the first time, I'd
be concerned as to whether anything that I'm using in RSS 1.0 has been
taken away, and how steep my upgrade path is going to be. The fact that
you can extend it in pretty much the same way, even to the extent of
being able to use the old admin module etc., is a pretty important fact.

Post by Hammond, Tony
1. Introduction [...] We would argue that RSS 1.0 (and by extension
1.1 ;) is not just for 'up-to-the minute' syndication but represents
a generic format for distributing content using a specific RDF
profile.

Agreed. We'll seek to re-word this. Ironically, given their
non-normative status, the Introduction and Motivation sections were
probably the most difficult to write :-)

Post by Hammond, Tony
2. Motivation. 'RSS 0.92, RSS 2.0, and Atom'. Is that right? - I
don't know. Is '0.92' more successful than '0.91'?

Actually, you're probably right. Before we published the specification,
I took googlecounts of various version numbers:

"RSS 0.9": 117,000
"RSS 0.90": 152,000
"RSS 0.91": 1,690,000
"RSS 0.92": 516,000
"RSS 1.0": 6,030,000
"RSS 1.1": 459
"RSS 2.0": 9,520,000
"RSS 3.0": 9,330

I was unable to include Atom, of course, due to its multiple senses.

I'd consider half a million mentions of RSS 0.92 rather successful, but
wouldn't mind switching to RSS 0.91 in the text in question.

Post by Hammond, Tony
2. Motivation. 'however, uptake for RSS 1.0 has been relatively
limited'. Again true? How limited is 'relatively'?

Relative to RSS 1.1, we hope. This is mainly Christopher's point, and
relates to the inception of RSS 1.1 in general: RSS 1.0 had features
that put him off to a great extent when he first came across the format,
and hence impeded his use thereof--and even his liking of RDF in
general. He subsequently came to understand that it really could be
improved; that time and circumstance had been the main reason behind
some of RSS 1.0's grotesquenesses, and that many other people shared his
beliefs. I just happened to be closest to him when he was venting.

As for me, I've been irritated by RSS 1.0 architecturally for different
reasons since at least November 2001 [1]. It's been wonderful to have a
chance to resolve them properly.

Post by Hammond, Tony
2. Motivation. 'developing the other descendant of RSS 1.0, Atom'.
Excuse me. I wasn't aware that Atom, as such, was a descendant of RSS
1.0.

More politically than technically. I do still like your little summary
diagram here though:

Loading Image...

But Atom was politically a response to Dave Winer's publishing RSS 2.0,
which itself was a response to RSS 1.0, and I think that more of the
latter camp went to Atom than to RSS 2.0 :-)

Post by Hammond, Tony
3. Just a minor point. The <url> element. Why?

Yes, I can safely say that <url> is one of the grotesquenesses. But our
intention has been to ensure that producers of RSS 1.0 have minimal
upgrade impact, which means that we're not opposed to people having a
harmless <url> element lying around. RSS 1.0 requires it, so RSS 1.1
deprecates it. We can always remove it in RSS 1.2.

Post by Hammond, Tony
Yours, vehemently opposed, etc.

Sincerely delighted, and with many thanks,

[1] <http://rdfig.xmlhack.com/2001/10/22/2001-10-22.html
#1003716141.040026>
--
Sean B. Palmer, http://inamidst.com/sbp/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Leigh Dodds]

...All other
feedback should be sent by responding to this thread, or by joining the
#rss1.1 channel on the irc.freenode.net IRC network.

Have sent this to the editors, but cc'ing here for wider comment:

I'm disappointed that the RSS 1.1 RDF/OWL schema doesn't make any
reference to the RSS 1.0 classes and properties. Wouldn't this have
been a nice demonstration of RDF format evolution?

Cheers,

L.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Post by Leigh Dodds
I'm disappointed that the RSS 1.1 RDF/OWL schema doesn't make any
reference to the RSS 1.0 classes and properties. Wouldn't this have
been a nice demonstration of RDF format evolution?

Yes. This would definitely make a worthwhile addition.

I argued a bit with Mark Pilgrim over his characterization as RSS 0.9
and 1.0 as being (mutually) incompatible in his classic "The myth of
RSS compatibility" [1]. In retrospect I think he's probably right,
because there isn't actually a schema relating 0.9 to 1.0.

If you included RSS 0.9 in a 1.0/1.1 mapping schema, you could
actually *reduce* the number of incompatible format out there by
introducing 1.1 ;-)

Cheers,
Danny.

[1] http://diveintomark.org/archives/2004/02/04/incompatible-rss
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Post by Leigh Dodds
I'm disappointed that the RSS 1.1 RDF/OWL schema doesn't make any
reference to the RSS 1.0 classes and properties. Wouldn't this have
been a nice demonstration of RDF format evolution?

Christopher has already dealt with this in a practical sense, but I want
here to deal with the underlying rationale. Sadly, any RSS 1.0 feed that
uses images incorporates <image> as both a nodeElement and a propElt,
which is mandated by the specification. In other words, rss:image is
used as both a class and a property. These are disjoint in OWL DL:

[[[
LVI, IOT, IOC, IDC, IOOP, IODP, IOAP, IOXP, IL, and IX are all pairwise
disjoint.
]]] - http://www.w3.org/TR/owl-semantics/rdfs.html#5.4

But moreover they're disjoint in common sense; the RSS 1.0 schema is
broken in this regard. So this is the main issue: that were we to
provide relationships to RSS 1.0, we'd be providing them to an
inconsistent schema. You don't define a bugfix release in terms of the
specification whose bugs you're fixing!

A related issue is the use of further constructs in the RSS 1.0 schema
(per [1]) that make it OWL Full, i.e. use of rdfs:Class:

[[[
NOTE: owl:Class is defined as a subclass of rdfs:Class. The rationale
for having a separate OWL class construct lies in the restrictions on
OWL DL (and thus also on OWL Lite), which imply that not all RDFS
classes are legal OWL DL classes. In OWL Full these restrictions do not
exist and therefore owl:Class and rdfs:Class are equivalent in OWL Full.
]]] - http://www.w3.org/TR/owl-ref/#ClassDescription

Note that the RSS 1.1 ontology is in OWL Full, but that it only uses an
OWL Full constuct in a two omittable places. After conversations with
Joe Geldart on the matter, we decided that these constructs (the use of
rdf:List, and one rdfs:Class elsewhere) was a beneficial restriction
that could easily be omitted for OWL DL and OWL Lite tools.

So though the RSS 1.0 rdfs:Class issue isn't a clincher, if we were to
declare RSS 1.1 terms as being equivalent to RSS 1.0 terms, we'd be
binding ourselves ever more tightly to OWL Full, which is inconvenient.
On the other hand, were we to define them as subClasses, it's possible
that we'd find that RSS 1.0 class instances are instances of that part
of rdfs:Class which is in the owl:complementOf owl:Class, so once again
there's a possibility that we'd be incompatible with OWL--though we'd
have to investigate this more carefully.

Note that my use of qualified cardinality constraints, a la DAML+OIL,
has already been raised as a point which isn't clearly covered by the
OWL Reference Guide: it suggests that qualified cardinalities are
unacceptable, but Sean Bechhofer's OWL validator passes it, so we're
unsure. We'll be changing them to unqualified cardinality constraints
anyway since this doesn't change the intended semantic but does, as far
as I know, make it OWL DL compatible.

We'll likely summarize these issues properly somewhere else, perhaps in
the next draft of the specification, and ask www-rdf-logic or the
nearest available OWL expert for more feedback.

[1] http://web.resource.org/rss/1.0/schema.rdf
--
Sean B. Palmer, http://inamidst.com/sbp/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Given that only a small proportion of RSS systems are actually using
RSS as RDF, it seems an unrealistic leap from RSS
1.0-Barely-A-Data-Model to RSS 1.1-the-Description-Logic-Ontology.

Ok, maybe it's a noble cause, in a "Life and Notable Adventures of
that Renown'd Markup RSS" kind of way, but not taking into account the
situation on the Web probably won't help long-term. But I don't think
it really matters - you should be able to get the best of both worlds
by loosening up a bit.

A rough-and-ready OWL Full mapping may be of immediate use to folks
wanted to merge data from 1.0 and 1.1 sources. A tight but reduced
1.0/1.1 OWL DL mapping may be useful to working in more restricted
domains or with pre-filtered data, but I can't see it getting much in
the wild in the very near future, where there's a good chance the XML
won't even be well-formed, let alone consistent with a DL. But yeah,
let's have one of those too.

Cheers,
Danny.

On Wed, 19 Jan 2005 16:26:11 +0000, Sean B. Palmer

Post by Sean B. Palmer

Post by Leigh Dodds
I'm disappointed that the RSS 1.1 RDF/OWL schema doesn't make any
reference to the RSS 1.0 classes and properties. Wouldn't this have
been a nice demonstration of RDF format evolution?

Christopher has already dealt with this in a practical sense, but I want
here to deal with the underlying rationale. Sadly, any RSS 1.0 feed that
uses images incorporates <image> as both a nodeElement and a propElt,
which is mandated by the specification. In other words, rss:image is
[[[
LVI, IOT, IOC, IDC, IOOP, IODP, IOAP, IOXP, IL, and IX are all pairwise
disjoint.
]]] - http://www.w3.org/TR/owl-semantics/rdfs.html#5.4
But moreover they're disjoint in common sense; the RSS 1.0 schema is
broken in this regard. So this is the main issue: that were we to
provide relationships to RSS 1.0, we'd be providing them to an
inconsistent schema. You don't define a bugfix release in terms of the
specification whose bugs you're fixing!
A related issue is the use of further constructs in the RSS 1.0 schema
[[[
NOTE: owl:Class is defined as a subclass of rdfs:Class. The rationale
for having a separate OWL class construct lies in the restrictions on
OWL DL (and thus also on OWL Lite), which imply that not all RDFS
classes are legal OWL DL classes. In OWL Full these restrictions do not
exist and therefore owl:Class and rdfs:Class are equivalent in OWL Full.
]]] - http://www.w3.org/TR/owl-ref/#ClassDescription
Note that the RSS 1.1 ontology is in OWL Full, but that it only uses an
OWL Full constuct in a two omittable places. After conversations with
Joe Geldart on the matter, we decided that these constructs (the use of
rdf:List, and one rdfs:Class elsewhere) was a beneficial restriction
that could easily be omitted for OWL DL and OWL Lite tools.
So though the RSS 1.0 rdfs:Class issue isn't a clincher, if we were to
declare RSS 1.1 terms as being equivalent to RSS 1.0 terms, we'd be
binding ourselves ever more tightly to OWL Full, which is inconvenient.
On the other hand, were we to define them as subClasses, it's possible
that we'd find that RSS 1.0 class instances are instances of that part
of rdfs:Class which is in the owl:complementOf owl:Class, so once again
there's a possibility that we'd be incompatible with OWL--though we'd
have to investigate this more carefully.
Note that my use of qualified cardinality constraints, a la DAML+OIL,
has already been raised as a point which isn't clearly covered by the
OWL Reference Guide: it suggests that qualified cardinalities are
unacceptable, but Sean Bechhofer's OWL validator passes it, so we're
unsure. We'll be changing them to unqualified cardinality constraints
anyway since this doesn't change the intended semantic but does, as far
as I know, make it OWL DL compatible.
We'll likely summarize these issues properly somewhere else, perhaps in
the next draft of the specification, and ask www-rdf-logic or the
nearest available OWL expert for more feedback.
[1] http://web.resource.org/rss/1.0/schema.rdf
--
Sean B. Palmer, http://inamidst.com/sbp/
Yahoo! Groups Links

--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Summary: expect mappings from RSS 1.0 to RSS 1.1, as popularly
requested, in the next draft (which'll hopefully be on Monday).

Post by Danny Ayers
A rough-and-ready OWL Full mapping may be of immediate use to folks
wanted to merge data from 1.0 and 1.1 sources. A tight but reduced
1.0/1.1 OWL DL mapping may be useful to working in more restricted
domains

You have this the wrong way around. OWL Full is *harder* to implement
than OWL DL since Full isn't decidable and DL is. So therefore you can
use off-the-shelf tools with DL, but you'll never see a tool claiming
implementation of OWL Full (except a syntax checker).

And if you really want to talk to me about pragmatism, I think you
should be talking about XSLT instead of RDF anyway. I've written a
couple of RDF rule-engines, and yet I still do RSS 1.0 -> RSS 1.1
transformations using XSLT, because it's the lowest cost solution.

In any case, since mappings are now a heavily requested feature, we'll
seek to make them available in the specification informatively. Expect
the normative ontology to be in either DL or Lite, too.

Post by Danny Ayers
there's a good chance the XML won't even be well-formed, let alone
consistent with a DL. But yeah, let's have one of those too.

Right. The more the merrier! :-)
--
Sean B. Palmer, http://inamidst.com/sbp/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Post by Sean B. Palmer
Summary: expect mappings from RSS 1.0 to RSS 1.1, as popularly
requested, in the next draft (which'll hopefully be on Monday).

There remains a good reason NOT to reference 1.0 from 1.1, the confusing way
1.0's model has some terms used for both predicates and classes should
perhaps be broken away from.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Post by Jon Hanna

Post by Sean B. Palmer
Summary: expect mappings from RSS 1.0 to RSS 1.1, as popularly
requested, in the next draft (which'll hopefully be on Monday).

There remains a good reason NOT to reference 1.0 from 1.1, the confusing way
1.0's model has some terms used for both predicates and classes should
perhaps be broken away from.

Yep, I think Sean might have it about right when talking about the
normative ontology being DL or Lite but looking at things through
informative XSLT spectacles when going from 10 to 1.1.

I do think clear advice on how to map/merge feeds should be given,
this is likely to be an immediate need for anyone wishing to consume
1.1. Translating from RSS 2.0 to RDF is relatively easy because
there's just a simple, very loosely-specified domain model to work
from. All hail XSLT. But with RSS 1.0 documents having an RDF model
already, well, it's a bit lumpier. But I *will* have 1.0 items
alongside 1.1 items in a triplestore - how do I run queries that will
work sensibly across both?

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Translating from RSS 2.0 to RDF is relatively easy because

Post by Danny Ayers
there's just a simple, very loosely-specified domain model to work
from. All hail XSLT. But with RSS 1.0 documents having an RDF model
already, well, it's a bit lumpier. But I *will* have 1.0 items
alongside 1.1 items in a triplestore - how do I run queries that will
work sensibly across both?

You could just take advantage of the fact that they work when viewed as XML
and use XSLT on one of them just as you do with 2.0.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

On Thu, 20 Jan 2005 22:54:36 +0000, Sean B. Palmer

Post by Sean B. Palmer
Summary: expect mappings from RSS 1.0 to RSS 1.1, as popularly
requested, in the next draft (which'll hopefully be on Monday).

Post by Danny Ayers
A rough-and-ready OWL Full mapping may be of immediate use to folks
wanted to merge data from 1.0 and 1.1 sources. A tight but reduced
1.0/1.1 OWL DL mapping may be useful to working in more restricted
domains

You have this the wrong way around. OWL Full is *harder* to implement
than OWL DL since Full isn't decidable and DL is. So therefore you can
use off-the-shelf tools with DL, but you'll never see a tool claiming
implementation of OWL Full (except a syntax checker).

I wasn't talking about implementing any such thing. I was talking
about merging data from the different sources. You had pointed out
places where the mapping couldn't work without breaking out of DL. I'm
suggesting that if you want to use real-world RSS 1.0 with RSS 1.1
then you'll have to be prepared to.

Post by Sean B. Palmer
And if you really want to talk to me about pragmatism, I think you
should be talking about XSLT instead of RDF anyway.

Yes, that would be one route to merging. But it would help to have a
mapping to begin.

I've written a

Post by Sean B. Palmer
couple of RDF rule-engines, and yet I still do RSS 1.0 -> RSS 1.1
transformations using XSLT, because it's the lowest cost solution.

Fine, it doesn't come as a surprise.

Post by Sean B. Palmer
In any case, since mappings are now a heavily requested feature, we'll
seek to make them available in the specification informatively. Expect
the normative ontology to be in either DL or Lite, too.

No objections there, I just felt "we can't do a pure mapping so we
won't do one at all" wasn't much use in pragmatic terms.

Post by Sean B. Palmer

Post by Danny Ayers
there's a good chance the XML won't even be well-formed, let alone
consistent with a DL. But yeah, let's have one of those too.

Right. The more the merrier! :-)

Indeedly-dee.

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Eric Miller]

Post by Leigh Dodds

...All other
feedback should be sent by responding to this thread, or by joining the
#rss1.1 channel on the irc.freenode.net IRC network.

I'm disappointed that the RSS 1.1 RDF/OWL schema doesn't make any
reference to the RSS 1.0 classes and properties. Wouldn't this have
been a nice demonstration of RDF format evolution?

+1

--
eric miller http://www.w3.org/people/em/
semantic web activity lead http://www.w3.org/2001/sw/
w3c world wide web consortium http://www.w3.org/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

A couple of late evening comments to my late first look at "RSS 1.1"

- I don't think that it is a good ideas to have urls as literal, use
named resources
- what's the link element for? I assume when used as property of Image
if should describe the link on that image, but what's the good as
property of Channel or Item?
- the image property has an xml:lang attribute, but this is not legal in
RDF as only plain-literals may have an xml:lang
- the image property is missing in the ontology (at least its not there
with a label)
- +1 for capitalizing all classes
- Why can a channel have only one title? I'm used to give them a title
property for every available language, same for description - and why
shouldn't multiple images be possible?

Regarding the design of the spec I would prefer to start with a
serialization independent definition of the ontology, and define the
concept of "RSS - Document" in a second section. This is to make clear
that usage of the RSS-Vocabulary is not limited to RSS Documents, does
not necessarily imply some specific serialization and is independent of
XML. By contrast an RSS-Document is an XML Document following the
defined syntax which happens to interpretable as RDF/XML as a graph
using RSS - like this people only interested in the vocabulary would not
be discouraged by irrelevant details.

reto





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Thanks for the ongoing comments everyone. We're simmering all the
feedback into a new draft, which we think will answer most concerns.

Post by Reto Bachmann-Gmuer
- the image property has an xml:lang attribute, but this is not legal
in RDF as only plain-literals may have an xml:lang

Wrong: elements inherit xml:lang from their parents, so it's valid at
any point in the tree. Try it in the RDF Validator [1].

Post by Reto Bachmann-Gmuer
- the image property is missing in the ontology (at least its not
there with a label)

Thanks; we'll fix this.

Post by Reto Bachmann-Gmuer
- Why can a channel have only one title?

It's a primary title, so that user agents don't have to choose between
them. You can use dc:title for alternatives. As Chris said elsewhere:

There's also the fact that most feeds simply don't have a need for
metadata to be used in this way: they have seperate RSS feeds for
different language. Tools don't expect the RDF way of doing things -
they want one title, not 4.

Thanks,

[1] http://www.w3.org/RDF/Validator/
--
Sean B. Palmer, http://inamidst.com/sbp/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Sean B. Palmer
Thanks for the ongoing comments everyone. We're simmering all the
feedback into a new draft, which we think will answer most concerns.

Post by Reto Bachmann-Gmuer
- the image property has an xml:lang attribute, but this is not legal
in RDF as only plain-literals may have an xml:lang

Wrong: elements inherit xml:lang from their parents, so it's valid at
any point in the tree. Try it in the RDF Validator [1].

right, but -as opposed to a dc:language property - it has no effect on
the Image resource but only on the plain-literals within it, given that
link is a plain-literal (but it should be XSD anyURI) the language
information applies also to this one, which seems a bit strange to me.

Post by Sean B. Palmer

Post by Reto Bachmann-Gmuer
- Why can a channel have only one title?

It's a primary title, so that user agents don't have to choose between
There's also the fact that most feeds simply don't have a need for
metadata to be used in this way: they have seperate RSS feeds for
different language. Tools don't expect the RDF way of doing things -
they want one title, not 4.

I don't think having separate RSS feeds with different URLs is a good
idea when using a protocol which supports language negotiation [1]. For
a page that supports multiple languages bot statement:

<http://wymiwyg.org/> <rss:title> "Willkommen bei wymiwyg"@de
<http://wymiwyg.org/> <rss:title> "Benvenuti da wymiwyg"@it

seem to be equally correct. In both stmts "rss:title" refers to the
primary title and so using a different property (like dc:title) does not
seem to justified. While for RDF-Applications I see no reason for
limiting the title to one - this may be reasonable for XML-Clients (I
don't know, I don't do XML), if this is the case it should be
constrained in the XML Schema - not in the ontology. This would allow
both of the above statements to be in the rdf-repository on the server,
but when a RSS document is delivered the title that best matches the
client's request is delivered.


reto


1. http://www.w3.org/International/questions/qa-when-lang-neg




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Sean B. Palmer
Thanks for the ongoing comments everyone. We're simmering all the
feedback into a new draft, which we think will answer most concerns.

Post by Reto Bachmann-Gmuer
- the image property has an xml:lang attribute, but this is not legal
in RDF as only plain-literals may have an xml:lang

Wrong: elements inherit xml:lang from their parents, so it's valid at
any point in the tree. Try it in the RDF Validator [1].

right, but -as opposed to a dc:language property - it has no effect on
the Image resource but only on the plain-literals within it, given that
link is a plain-literal (but it should be XSD anyURI) the language
information applies also to this one, which seems a bit strange to me.

Post by Sean B. Palmer

Post by Reto Bachmann-Gmuer
- Why can a channel have only one title?

It's a primary title, so that user agents don't have to choose between
There's also the fact that most feeds simply don't have a need for
metadata to be used in this way: they have seperate RSS feeds for
different language. Tools don't expect the RDF way of doing things -
they want one title, not 4.

I don't think having separate RSS feeds with different URLs is a good
idea when using a protocol which supports language negotiation [1]. For
a page that supports multiple languages bot statement:

<http://wymiwyg.org/> <rss:title> "Willkommen bei wymiwyg"@de
<http://wymiwyg.org/> <rss:title> "Benvenuti da wymiwyg"@it

seem to be equally correct. In both stmts "rss:title" refers to the
primary title and so using a different property (like dc:title) does not
seem to justified. While for RDF-Applications I see no reason for
limiting the title to one - this may be reasonable for XML-Clients (I
don't know, I don't do XML), if this is the case it should be
constrained in the XML Schema - not in the ontology. This would allow
both of the above statements to be in the rdf-repository on the server,
but when a RSS document is delivered the title that best matches the
client's request is delivered.


reto


1. http://www.w3.org/International/questions/qa-when-lang-neg






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Post by Reto Bachmann-Gmuer
- I don't think that it is a good ideas to have urls as literal, use
named resources

Named resources are of value when talking about resources, but not when
talking about the URIs themselves.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Jon Hanna

Post by Reto Bachmann-Gmuer
- I don't think that it is a good ideas to have urls as literal, use
named resources

Named resources are of value when talking about resources, but not when
talking about the URIs themselves.

Does it make sense to talk about the URIs themselves? All the properties
of rss:Item and rss:Channel apply to the information resource named with
the URL which is currently the value of the rss:link property [1]. It
seems to me to unnecessarily increase the complexity of the graph to
recommend channels and items to be anonymous, but even if the channel
and the web-page where the representation of the channel can be
retrieved are considered to be two different things I see no reason not
to model the latter as names resource allowing it to be the subject of
statements (there is an obvious relation (if not identity) between the
resource of type channel with title "My Blog" and the resource which can
be dereferenced to a page with the title "My Blog", this relation seems
to me much stronger than the one to the "URI itself").

In contrast the Image resource should be anonymous, as its properties
like rss:title do not necessarily apply to the image as such but rather
to the function role of the image within the channel or item.

reto


1. I've read
http://internetalchemy.org/wiki/RssIssues/IssueRequiredRdfAbout, but
actually I have no problem agreing with a statement like

<http://example.org/#my-first-article> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type%3E> <http://purl.org/rss/1.0/item> <http://purl.org/rss/1.0/item%3E>

In fact in KnoBot such a statement is contained in the answer to an MGET request to the URL of a regular article.




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

First off, let's be sure to balance between fixing (whatever that means) the
outstanding, but minor, issues with the 1.0 form and breakage of existing
tools. Changing something that will break existing tools better damn well
have a pretty compelling use case (and not just RDF voodoo). I'm all for
the voodoo-value but recognize not everyone buys into it.

Post by Reto Bachmann-Gmuer
- what's the link element for? I assume when used as property of Image
if should describe the link on that image, but what's the good as
property of Channel or Item?
- the image property is missing in the ontology (at least its not there
with a label)

How the image element of a channel evolved has always been a bit broken. As
long as it persists are being useful for a 88x31 sidebar icon I've little
argument with taking steps to fix it's defects.

Post by Reto Bachmann-Gmuer
- the image property has an xml:lang attribute, but this is not legal in
RDF as only plain-literals may have an xml:lang
- Why can a channel have only one title? I'm used to give them a title
property for every available language, same for description - and why
shouldn't multiple images be possible?

Dealing with multi-lingual applications is a mess. I continue to think it's
just better to make them separate feeds. Too many of the tools do not have
the ability to deal with compound feeds. Either as 'more than one feed in
the document' or as multi-lingual representations of the 'same' data within
a single feed. I'd rather see development of mutiple feeds within a single
document long before multilingual. Not as a bias against expressing content
more flexibly but as a preference to solve other problems first. I think
that by dealing with a single document containing multiple feeds it'll make
it easier to deal with multilingual content.

Post by Reto Bachmann-Gmuer
Regarding the design of the spec I would prefer to start with a
serialization independent definition of the ontology, and define the
concept of "RSS - Document" in a second section. This is to make clear
that usage of the RSS-Vocabulary is not limited to RSS Documents, does
not necessarily imply some specific serialization and is independent of
XML. By contrast an RSS-Document is an XML Document following the
defined syntax which happens to interpretable as RDF/XML as a graph
using RSS - like this people only interested in the vocabulary would not
be discouraged by irrelevant details.

What use-case can you offer that better illustrates what you're talking
about here? It's not clear just what you mean.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

Post by Bill Kearney
Dealing with multi-lingual applications is a mess. I continue to think it's
just better to make them separate feeds. Too many of the tools do not have
the ability to deal with compound feeds. Either as 'more than one feed in
the document' or as multi-lingual representations of the 'same' data within
a single feed. I'd rather see development of mutiple feeds within a single
document long before multilingual. Not as a bias against expressing content
more flexibly but as a preference to solve other problems first. I think
that by dealing with a single document containing multiple feeds it'll make
it easier to deal with multilingual content.

Having multiple feeds for different languages is a way to go, however I
don't think parses should have so big problems encountering multiple
title-tags to make it necessary to forbid effectively multi-lingual
content. It brings some advantages to have different language versions
share the same URL: several-meta information (like user rating) is
language independent - it is handy if one can recommend an article to
persons speaking other languages by its URI.

Post by Bill Kearney

Post by Reto Bachmann-Gmuer
Regarding the design of the spec I would prefer to start with a
serialization independent definition of the ontology, and define the
concept of "RSS - Document" in a second section. This is to make clear
that usage of the RSS-Vocabulary is not limited to RSS Documents, does
not necessarily imply some specific serialization and is independent of
XML. By contrast an RSS-Document is an XML Document following the
defined syntax which happens to interpretable as RDF/XML as a graph
using RSS - like this people only interested in the vocabulary would not
be discouraged by irrelevant details.

What use-case can you offer that better illustrates what you're talking
about here? It's not clear just what you mean.

OK, let's try.

UC 1
The user is primarily using other RDF-Schemas (like one who wants to add
the rss:items he last wrote to it's foaf-information), she doesn't care
about the serialization details, it should be possible for her to see a
documentation of the RSS-Vocabulary without all the noise of
XML-Details. (This user doesn't have to know about rss-documents)

UC 2
The user created an RSS:Channel with an RDF-editor, standard "save as
RDF/XML" will not create a valid RSS-File, thus she will have to choose
"save as RSS", she will be asked to specify the primary channel of the
RSS-file and the primary language, the model will be stored as valid RSS
file but still contain all the triples of the model. For this to be
possible RDF tools developers should have a documentation of the
serialization as a subset of RDF/XML.

UC 3
The user knows nothing about RDF and doesn't care. It should be possible
for him to just have described in term of XML how to create or parse an
RSS-Document, he doesn't have to care about the RDF-Vocabulary, triples
are a side effect without consequence. (This user doesn't have to know
about the rss-vocabulary)

reto






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

A couple of late evening comments to my late first look at "RSS 1.1"

- I don't think that it is a good ideas to have urls as literal, use
named resources
- what's the link element for? I assume when used as property of Image
if should describe the link on that image, but what's the good as
property of Channel or Item?
- the image property has an xml:lang attribute, but this is not legal in
RDF as only plain-literals may have an xml:lang
- the image property is missing in the ontology (at least its not there
with a label)
- +1 for capitalizing all classes
- Why can a channel have only one title? I'm used to give them a title
property for every available language, same for description - and why
shouldn't multiple images be possible?

Regarding the design of the spec I would prefer to start with a
serialization independent definition of the ontology, and define the
concept of "RSS - Document" in a second section. This is to make clear
that usage of the RSS-Vocabulary is not limited to RSS Documents, does
not necessarily imply some specific serialization and is independent of
XML. By contrast an RSS-Document is an XML Document following the
defined syntax which happens to interpretable as RDF/XML as a graph
using RSS - like this people only interested in the vocabulary would not
be discouraged by irrelevant details.

reto







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Leigh Dodds]

re: http://inamidst.com/rss1.1/#cc-ENCODING

"The character encoding of RSS 1.1 documents MUST be either UTF-8,
UTF-16, or UTF-32 per requirement C018 of the Character Model for the WWW."

Later in the spec:

"Since US-ASCII is a subset of UTF-8, users MAY use US-ASCII as the
encoding for RSS 1.1 documents. An explicit charset parameter MUST be
used when serving an RSS 1.1 document as anything other than US-ASCII."

Surely if I MUST use UTF8/16/32, then I can't use US-ASCII? Yes, it's
a subset, but I read the first requirement to say that the charset
and document encoding MUST be UTF8/16/32, so I don't see how that allows
me to use US-ASCII instead?

Where does the requirement to restrict possible encodings come from?
(Just curious, probably a lengthy debate which I missed). Why not
SHOULD use UTF8/16/32 but MAY use others, e.g. USASCII.

Cheers,

L.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Post by Leigh Dodds
"Since US-ASCII is a subset of UTF-8, users MAY use US-ASCII as the
encoding for RSS 1.1 documents. An explicit charset parameter MUST be
used when serving an RSS 1.1 document as anything other than
US-ASCII."
Surely if I MUST use UTF8/16/32, then I can't use US-ASCII? Yes, it's
a subset, but I read the first requirement to say that the charset
and document encoding MUST be UTF8/16/32, so I don't see how
that allows
me to use US-ASCII instead?

If you use US-ASCII but label it as UTF-8 it will work, since the UTF-8
encoding for all characters catered for by US-ASCII is identical to the
US-ASCII encoding.

Post by Leigh Dodds
Where does the requirement to restrict possible encodings come from?
(Just curious, probably a lengthy debate which I missed). Why not
SHOULD use UTF8/16/32 but MAY use others, e.g. USASCII.

All XML parsers can handle UTF-8 and UTF-16 it is good practice to only
output in one of those. In practice sticking with UTF-8 is generally a good
idea.

Having said that, I don't recommend UTF32 for bytes-on-the-wire and saying
one SHOULD output in UTF-8 or UTF-16 (and perhaps informally recommending
UTF-8), MUST accept UTF-8 and UTF-16 and MAY use other encodings as per the
XML rules for doing so would be consistent with C018.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Post by Jon Hanna
If you use US-ASCII but label it as UTF-8 it will work, since the
UTF-8 encoding for all characters catered for by US-ASCII is
identical to the US-ASCII encoding.

Right. I think that this is clear in the RSS 1.1 specification, but
we're going to try to make it clearer anyway.

Post by Jon Hanna
I don't recommend UTF32 for bytes-on-the-wire and saying one SHOULD
output in UTF-8 or UTF-16 (and perhaps informally recommending
UTF-8), MUST accept UTF-8 and UTF-16 and MAY use other encodings as
per the XML rules for doing so would be consistent with C018.

Yes, this is based on a misreading of C018, as Bjoern Hoehrmann has
already pointed out, and will be fixed in the next draft. We'll be
requiring UTF-8 as the encoding, the same as RSS 1.0, and trying to make
the section on US-ASCII clearer.

Cheers,
--
Sean B. Palmer, http://inamidst.com/sbp/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Klaus Johannes Rusch]

Post by Sean B. Palmer

Post by Jon Hanna
If you use US-ASCII but label it as UTF-8 it will work, since the
UTF-8 encoding for all characters catered for by US-ASCII is
identical to the US-ASCII encoding.

Right. I think that this is clear in the RSS 1.1 specification, but
we're going to try to make it clearer anyway.

The codepoints are the same if you only use US-ASCII characters.
US-ASCII characters are included in most commonly used encodings,
nevertheless the specification should be clear on whether or not other
encodings are allowed.

Post by Sean B. Palmer

Post by Jon Hanna
I don't recommend UTF32 for bytes-on-the-wire and saying one SHOULD
output in UTF-8 or UTF-16 (and perhaps informally recommending
UTF-8), MUST accept UTF-8 and UTF-16 and MAY use other encodings as
per the XML rules for doing so would be consistent with C018.

Yes, this is based on a misreading of C018, as Bjoern Hoehrmann has
already pointed out, and will be fixed in the next draft. We'll be
requiring UTF-8 as the encoding, the same as RSS 1.0, and trying to make
the section on US-ASCII clearer.

RSS 1.0 does not require UTF-8 encoding, nor should it. In fact the RSS
1.0 specification indicates that UTF-8 is the default, but other
encodings can be specified, and specifies that the XML declaration is
mandatory if another encoding is used:

/Syntax:/ <?xml version="1.0"?>
/Requirement:/ Optional (unless specifying encoding)
--
Klaus Johannes Rusch
KlausRusch-***@public.gmane.org
http://www.atmedia.net/KlausRusch/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

Post by Klaus Johannes Rusch
RSS 1.0 does not require UTF-8 encoding, nor should it. In fact the RSS
1.0 specification indicates that UTF-8 is the default, but other
encodings can be specified, and specifies that the XML declaration is
/Syntax:/ <?xml version="1.0"?>
/Requirement:/ Optional (unless specifying encoding)

This is an XML thing, not something specific to RSS. As it should be.

If an document does not declare and encoding it's to be interpreted as
UTF-8. This is an XML requirement. No document need state an encoding if
it's using UTF-8. It can't "hurt" but it's not needed. If an encoding
other than UTF-8 is being used it's REQUIRED that it be expressed as such.

Noting, however, that many folks misunderstand that numeric references are
ALWAYS from Unicode, not the document's encoding (if it's not unicode). As
in, you can't express a windows-1252 smart quote using a &# numeric
reference.

I'm concerned that ill-informed discussions about encoding are going to
cause more trouble than it's worth. What people assume about encoding is a
TREMENDOUS mess. Talking about something being 'required' as UTF-8 is
fundamentally a VERY bad idea. Stepping back to us-ascii is an even WORSE
idea.

If a document is in UTF-8, then it's done. If it's us-ascii then it's
entirely reasonable to assume that it's utf-8. If something wanted to be
pedantic about it then declaring it as such would be fine. But it's not
needed. The wording regarding encoding in Section 4 is wrong in enough ways
that it needs to be rewritten entirely.

This text should be DELETED completely: "Since US-ASCII is a subset of
UTF-8, users MAY use US-ASCII as the encoding for RSS 1.1 documents. An
explicit charset parameter MUST be used when serving an RSS 1.1 document as
anything other than US-ASCII. "

I also dislike the use of namespaces on the examples. Naive users tend to
misunderstand them. They're better left in the document heading instead.

I think this begs the question, however, of what are you expecting to be
handled by this?

-Bill Kearney
Syndic8.com






Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Klaus Johannes Rusch]

Post by Bill Kearney
This text should be DELETED completely: "Since US-ASCII is a subset of
UTF-8, users MAY use US-ASCII as the encoding for RSS 1.1 documents. An
explicit charset parameter MUST be used when serving an RSS 1.1 document as
anything other than US-ASCII. "

So that would imply that, contrary to how XML is interpreted in the
absense of an XML declaration, a document would be interpreted as
US-ASCII instead of UTF-8 (and if it contained any characters outside of
the US-ASCII repertoire would therefore be invalid?)

IMHO there is no need to redefine how encodings work in XML, a reference
to the XML 1.0 specification should suffice, possibly with a
recommendation to encode the feed as US-ASCII or UTF-8 and a
non-normative notice that numeric entities refer to Unicode codepoints
and HTML entities cannot be used.
--
Klaus Johannes Rusch
KlausRusch-***@public.gmane.org
http://www.atmedia.net/KlausRusch/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Dan Brickley]

Post by Leigh Dodds
re: http://inamidst.com/rss1.1/#cc-ENCODING
"The character encoding of RSS 1.1 documents MUST be either UTF-8,
UTF-16, or UTF-32 per requirement C018 of the Character Model for the WWW."

Hmm. I think there are bunch of Japanese RSS feeds that use Shift_JIS.

http://www.syndic8.com/stats.php?section=overview doesn't seem to have
charset info, though perhaps it is there somewhere...

Dan





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Hammond, Tony]

Hey. I'm in no way against representing Classes/properties as such - as long
as it's done _consistently_ down the hierarchy (in XML). Seems to me that
the <item> element (as Dan has already pointed out) should be a class (and
hence capitalized), so that there is some kind of symmetry between Channel
and Item. The thing that immediately jumps out is having one element - the
root element - only capitalized. Just instinctively looks wrong. Things
should look right IMHO.

(If I inadvertently misused the word 'striping' in the previous post, it was
purely to refer to the XML element tag name representation of classes and
properties as being traditionally rendered as uppercase and lowercase,
respectively.)

Tony

-----Original Message-----
Sent: 19 January 2005 11:48
To: Jon Hanna
Subject: Re: [RSS-DEV] RSS 1.1
On Wed, 19 Jan 2005 11:16:24 -0000, Jon Hanna

Post by Jon Hanna

Post by Hammond, Tony
1. The one thing that really sticks out for me is the (rather
silly?) capitalization on the 'Channel' element which looks like a

The one thing that really sticks out for me is that they

had the sense

Post by Jon Hanna
to capitalise the Channel element. YMMV.

Heh. I'm with Dan on this one - RDF/XML is easier to read
with the Class/property convention. (Or following the CDF
precedent, all elements shouting ;-)
Generally, this does seem like a pretty reasonable
improvement over 1.0, but - this should have been RSS 2.0!
I anticipated 1.0.1/1.1 to be max-compatibility bugfix only,
so this this version came as a bit of a surprise. It doesn't
seem to have direct compatibility beyond being RDF & XML. I
won't try to speculate what this means in the world at large...
I'm not sure about the containment business. I don't think
the justification of syntax similarity to RSS 0.9x/2.0 really
counts for much. What's needed IMHO is the expression that
*all* the items from all feed documents from that URI are in
the same container or collection. I don't think having lots
of 15-item Collections will help (I hope to be proved wrong).
Personally I'd probably have got rid of <items> altogether,
and added a <inChannel> property to each item. If order's
needed (is it?), make it explicit with <previous>.
I'd also have the channel URI as the feed rather than feed or
homepage.
What might well be useful are normative mappings from/to
Atom, RSS 1.0 and RSS 2.0.
Cheers,
Danny.
--
http://dannyayers.com

********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with
registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

On Wed, 19 Jan 2005 12:10:12 -0000, Hammond, Tony <T.Hammond-F/0MNWz/qG3QT0dZR+***@public.gmane.org> wrote:

Just instinctively looks wrong. Things

Post by Hammond, Tony
should look right IMHO.

Absolutely.

Tut, tut, Mr.Palmer, your code aesthetics are usually sublime ;-)
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Sean B. Palmer]

Post by Hammond, Tony
I'm in no way against representing Classes/properties as such - as
long as it's done _consistently_ down the hierarchy (in XML).

Consistency with RDF convention is a binary thing: either you follow
that convention or you do not. Regardless of the fact that our use of a
single capitalized RDF class is tantalizing, we have chosen to use
entirely lowercase elements inside the capitalized root, and hence the
XML convention.

Note that RSS 1.0 followed the same principle, that of a capitalized
root element and lowercase children, but that we've since dropped the
inconsistent rdf:Seq. In other words, RSS 1.0 also mixed Class and
class, but at least RSS 1.1 only does so at the root.

Moreover, since the uptake of RSS 1.0 presumably wasn't hampered on the
(purely aesthetic) shunning of class capitalization, we don't believe
that it'll be an important factor in RSS 1.1 either.

Thanks,
--
Sean B. Palmer, http://inamidst.com/sbp/




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

On Wed, 19 Jan 2005 14:57:02 +0000, Sean B. Palmer

Post by Sean B. Palmer
Moreover, since the uptake of RSS 1.0 presumably wasn't hampered on the
(purely aesthetic) shunning of class capitalization, we don't believe
that it'll be an important factor in RSS 1.1 either.

There's a small benefit for class capitalization (easier to read), and
a small benefit for all lower-case (less likely to confuse plain-XML
people, if they got this far...). Either way there's also a small
aesthetic benefit.

What would be the cost of consistency?

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kevin A. Burton]

Post by Sean B. Palmer
On behalf of an independent group of RSS 1.0 users, I'm pleased to
announce the following specification and toolset for the consideration
http://inamidst.com/rss1.1/
- RSS 1.1 Specification

I didn't have time to review the spec last night... was very busy.

Right off the bat I'm really -1 to this whole thing. There's no way that
any of the existing RSS parsers will be able to support this. If its
RSS 1.1 it should be backwards compatible at a MINIMUM with RSS 1.0. An
RSS 1.0 parser should be able to parse RSS 1.1 or call it something
else. RSS 3.0 ....

As an implementor I'll have to go through a lot of trouble to support
RSS 1.1 and I don't want to do it... Its not necessary.

Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!

Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

Post by Kevin A. Burton

Post by Sean B. Palmer
On behalf of an independent group of RSS 1.0 users, I'm pleased to
announce the following specification and toolset for the consideration
http://inamidst.com/rss1.1/
- RSS 1.1 Specification

I didn't have time to review the spec last night... was very busy.
Right off the bat I'm really -1 to this whole thing. There's no way that
any of the existing RSS parsers will be able to support this.

Although I understand what you're saying with this statement, I would like
to point out that some aggregators do support RSS 1.1 with no changes:
specifically, Blam!, which uses RSS.Net for parsing, supports RSS 1.1
feeds with no changes at all.

Post by Kevin A. Burton
If its
RSS 1.1 it should be backwards compatible at a MINIMUM with RSS 1.0.
An
RSS 1.0 parser should be able to parse RSS 1.1 or call it something
else. RSS 3.0 ....

RSS 3.0 is already taken, although in jest, by two different
specifications: Aaron Swartz's 3.0[1] and Dan Brickley's RSS 3.0, which
was at http://groups.yahoo.com/group/rss3 but seems to have been wiped
from the servers at some point. (The original message is still
available[2], however.) To use this name would confuse the syndication
issue even more than it already is, a problem which no one wants to
encourage, least of all Sean or I.

Post by Kevin A. Burton
As an implementor I'll have to go through a lot of trouble to support
RSS 1.1 and I don't want to do it... Its not necessary.

And that's acceptable. We've outlined the Specification for review
by the community: that does not mean in any way that people are
required to implement it. There are probably no aggregators out there
which handle every format that there is, and that's not a problem: if
people want to use a specific type of feed, they will use a tool which
supports it. Does it create somewhat of a mess? Yes, unfortunately,
but these things happen, and life goes on.

RSS 1.1 is not designed to force tool designers to do anything: our
goal was not to create a competitor to any syndication format. It was
primarily designed to fill the need for an improved version of RSS 1.0.
Given the relatively small differences between RSS 1.0 and RSS 1.1, I
disagree that it is a complete revolution from RSS 1.0.

Most RSS 1.0-friendly aggregators will still have problems aggregating
RSS 0.9. There is no change small enough that you can maintain complete
backwards compatibility in all tools: We strove instead to make it
relatively simple for implementors to implement the changes we did choose
to make. Given the fact that there are already multiple aggregators which
support RSS 1.1, I think that we did relatively well in that goal.

I'm sorry that you feel it's not worth your time as an implementor to
support RSS 1.1, but I respect that decision. I hope that as further
discussion occurs, you may change your mind.

[1] http://aaronsw.com/2002/rss30
[2] http://groups.yahoo.com/group/rss-dev/message/2076

Regards,
--
Christopher Schmidt




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

Post by Christopher Schmidt
Although I understand what you're saying with this statement, I would like
specifically, Blam!, which uses RSS.Net for parsing, supports RSS 1.1
feeds with no changes at all.

Let's be VERY careful here. It treads quite dangerously toward the problems
associated with coddling bad tools. That a given tool doesn't PROPERLY
throw errors on this 1.1 format is a BAD SIGN for that tool.

Post by Christopher Schmidt
Given the fact that there are already multiple aggregators which
support RSS 1.1, I think that we did relatively well in that goal.

Again, it does little to build any real credibility to base acceptance based
on the failure to disrupt bad tools.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Christopher Schmidt]

Post by Bill Kearney

Post by Christopher Schmidt
Although I understand what you're saying with this statement, I would like
specifically, Blam!, which uses RSS.Net for parsing, supports RSS 1.1
feeds with no changes at all.

Let's be VERY careful here. It treads quite dangerously toward the problems
associated with coddling bad tools. That a given tool doesn't PROPERLY
throw errors on this 1.1 format is a BAD SIGN for that tool.

I don't think this is neccesarily true. Given that any tool which is not
RSS 1.1 specific has to have accept a wide variety of formats with a
relatively wide spread of variation, the fact that a tool may support
things which are not exactly what they claim to be - things which are
almost-RSS 1.0, for example - does not neccesarily mean that the tool is
broken.

RSS 1.1 is very close to RSS 1.0 in many ways, so it is not surprising
that tools may handle the feeds with no changes. That was one of the
goals in the first place: to resolve as many issues as possible with as
few changes to the way the content was presented as possible.

The only things that a User-Agent is required to throw errors on is
invalid XML. There are a number of other things which they may throw
errors on, but in general we've attempted to encourage Postel's Law: "Be
liberal in what you accept, and conservative in what you send." The only
thing this does not apply to is invalid XML, which should be dumped on
the floor. I don't have any information on what Blam does about this,
but any tool which does not fail on invalid XML is a non-conforming
aggregator.

Post by Bill Kearney

Post by Christopher Schmidt
Given the fact that there are already multiple aggregators which
support RSS 1.1, I think that we did relatively well in that goal.

Again, it does little to build any real credibility to base acceptance based
on the failure to disrupt bad tools.

This part of my previous email was referring to the developers who have
integrated changes into their tools specifically to support RSS 1.1,
rather than tools which may, due to peculiarities of coding, support it.
JabRSS[1] and BottomFeeder[2] have both added support since the release
of the specification. (BottomFeeder had it within 3 hours.)

[1] http://cmeerw.org/dev/taxonomy/term/1
[2] http://www.cincomsmalltalk.com/BottomFeeder/

Regards,
--
Christopher Schmidt



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

Post by Christopher Schmidt
I don't think this is neccesarily true.

You're free to disagree.

Post by Christopher Schmidt
things which are
almost-RSS 1.0, for example - does not neccesarily mean that the tool is
broken.

Madness. Just plain madness. Have we not drilled this insanity out of
developer's heads already? Why are so many people putting such energies
into working around stupid shit like badly formatted feeds instead of just
fixing them or the tools making them? The latter is a HELL OF A LOT EASIER
than the crap that has to get added to an aggregator to catch them. It's
even easier when people that one would think should know better don't cloud
the issue with excuses.

Post by Christopher Schmidt
but in general we've attempted to encourage Postel's Law: "Be
liberal in what you accept, and conservative in what you send."

Do not dress up bad practices by paraphrasing a dead man's intentions.
While I'm all for the idea of avoiding disruptions of the *end user's*
experience I don't think coddling bad developers rises to the intentions
Postel had in mind. It's one thing for a feed tool to try working past a
few trivial errors. It's another (unacceptable) thing to try justifying
that as a baked-in part of the format.

Post by Christopher Schmidt
This part of my previous email was referring to the developers who have
integrated changes into their tools specifically to support RSS 1.1,
rather than tools which may, due to peculiarities of coding, support it.
JabRSS[1] and BottomFeeder[2] have both added support since the release
of the specification. (BottomFeeder had it within 3 hours.)

And given that it's not even a standardized format presents yet another
range of legacy issues.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Cecelia Hickel]

Would it not be a good idea then to discuss the currently available tools specifically as to their credits (or discredits) and keep track of those tools which perform according to the specifications and do in fact respect all this effort by so many folks committed to doing these correctly.

I see two issues here, one issue regarding the willingness of others to move towards adoption of new developments both quickly and willingly and those folks that never do. The greater question also is of course, which adoptions are correctly applied?

While it may serve this community to emphasize the source of sloppy noncompliant work is from developers and their adoption practices ( halfway or close is good enough) and strongly noting the extra work it places on developers to cleanup the mess is quite fair, this comminuty has the mandate to peer review such tools and identify which falls short and perhaps provide some helpful guidance to a developer before a slaughter. Implementation is the key to success in all cases of software development. Standards groups work hard and develop the standard but there is no oversight to impementation, only reccomendations. Which of course is correct, but there is no accountability(QA) of development and practices for those tools which claim the standard. There is no certification or conformace checks. What remains then is peer review which is powerful indeed. If the developers care abot this gr
oups opinion, they wil listen and fix their problems, ask for help and perhaps contribute valuable
data for better standards.

Peer review can perhaps clean up messes ahead of time. If it is broken, do not use it.

The excuse for bad code might be nothing more than a young programmers mistake or a misunderstanding of the specification, or some other nonintentional error. Surely, most mistakes and failures to meet specification requirments are nonintentional. At least I hope so.

My suggestion is for the group to find compliant tools and use those, help correct the bad tools or simply ban them as nonstandard tools. I hate to think of all the trial an error experience using available tools that exists in this group goes to waste over nonproductive disputes.

Post by Christopher Schmidt
I don't think this is neccesarily true.

You're free to disagree.

Post by Christopher Schmidt
things which are
almost-RSS 1.0, for example - does not neccesarily mean that the tool is
broken.

Madness. Just plain madness. Have we not drilled this insanity out of
developer's heads already? Why are so many people putting such energies
into working around stupid shit like badly formatted feeds instead of just
fixing them or the tools making them? The latter is a HELL OF A LOT EASIER
than the crap that has to get added to an aggregator to catch them. It's
even easier when people that one would think should know better don't cloud
the issue with excuses.

Post by Christopher Schmidt
but in general we've attempted to encourage Postel's Law: "Be
liberal in what you accept, and conservative in what you send."

Do not dress up bad practices by paraphrasing a dead man's intentions.
While I'm all for the idea of avoiding disruptions of the *end user's*
experience I don't think coddling bad developers rises to the intentions
Postel had in mind. It's one thing for a feed tool to try working past a
few trivial errors. It's another (unacceptable) thing to try justifying
that as a baked-in part of the format.

Post by Christopher Schmidt
This part of my previous email was referring to the developers who have
integrated changes into their tools specifically to support RSS 1.1,
rather than tools which may, due to peculiarities of coding, support it.
JabRSS[1] and BottomFeeder[2] have both added support since the release
of the specification. (BottomFeeder had it within 3 hours.)

And given that it's not even a standardized format presents yet another
range of legacy issues.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links









Cecelia Hickel
cjhickel-/***@public.gmane.org
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Non-text portions of this message have been removed]







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[l***@public.gmane.org]

Post by Bill Kearney
Madness. Just plain madness. Have we not drilled this insanity out of
developer's heads already? Why are so many people putting such energies
into working around stupid shit like badly formatted feeds instead of just
fixing them or the tools making them?

Bill,

I share your sentiment and also think that developers should take
standards compliance more seriously.

The philosphy which you call "madness" is very common and
usually summed up with the phrase:

"Be liberal in what you accept, and conservative in what you send"

I think it is reasonable approach to get around in imperfect world
where many tools are just out of your control and you could not fix
them all.

Bit of personal history: Few years ago for one of projects we have to
write HTML parser. I wrote it to follow HTML spec to the letter
(including some obscure aspects coming from SGML heritage). I wrote
unit tests and run it through various HTML test suites to ensure it is
compliant to the standard. Once we tried to use it on real web pages,
I found out to my horror that roughly 80-90% of common web pages are
not valid according to HTML spec. When we spent weeks doing various
heuristics and workarounds to make it work properly on most pages we
need to process. Next problem was that popular web browser (IE and
Netscape at the time) were using different heuristics and error
recovery strategies and same broken page was still shown in them,
albeit slightly differently. We had to figure out and emulate the
behavior of most of them. That was what I call "plain madness".

But what option did I have? To tell my customers that the 80% of web
pages they are viewing in their browser do not follow HTML standard
and we could not process them?

Vadim







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

I think it is reasonable to report an error and then, as part of that error,
an attempt to work around that error. I think this holds even in the case of
ill-formed XML (the spec says you must report an error, not how that error
must be reported).

"This feed is invalid, the following is an attempt to interpret it anyway
but may differ from the author's intent:..." gives the end user something
they can use and the author the heads-up that they need to fix their feed.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Post by Jon Hanna
I think it is reasonable to report an error and then, as part of that error,
an attempt to work around that error. I think this holds even in the case of
ill-formed XML (the spec says you must report an error, not how that error
must be reported).

In that specific case of ill-formed XML I believe the spec'd behaviour
is for the parser to stop dead in its tracks. XML isn't robust in the
Postel sense, though an app using it may be. But I've been through the
mill a lot of times on this on the Atom list, mostly arguing from the
more Draconian point of view. At this stage in the game, I can't see
any developer of existing (popular aggregator) tools making their
input section respond by rejecting the data altogether. If the spec
says it's a no-no, I reckon it'll be widely ignored, if the spec says
it's ok, new developers will be as liberal as the old. So as a
realistic compromise I suppose a very clear error message SHOULD be
given (maybe with the opportunity to manually notify etc etc), or the
app MAY just ditch the stuff altogether.

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jon Hanna]

Post by Jon Hanna

Post by Jon Hanna
I think it is reasonable to report an error and then, as

part of that error,

Post by Jon Hanna
an attempt to work around that error. I think this holds

even in the case of

Post by Jon Hanna
ill-formed XML (the spec says you must report an error, not

how that error

Post by Jon Hanna
must be reported).

In that specific case of ill-formed XML I believe the spec'd behaviour
is for the parser to stop dead in its tracks.

Stop dead in its tracks, and also report an error when the processing is
done in a context where reporting errors makes sense (e.g. an interactive
process such as a browser). So it can still produce an estimation of what
would have been produced if it was part of the error message.

Sure this is pretty much attempting to find a loophole, but as long as the
error message looks like an error message and smells like an error message I
think it keeps to the spirit as well as the word of the spec.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[ecomputerd]

It is very unlikely that a popular aggregator would reject invalid
RSS altogether. If any aggregator is able to read the feed, one of
the first things the developer will hear is "I can read the feed
with YYY reader, why not yours?" This has been my experience.

Greg Smith
Author, FeederReader - The Pocket PC RSS reader and podcatcher
www.FeederReader.com

Post by Danny Ayers

Post by Jon Hanna
I think it is reasonable to report an error and then, as part of that error,
an attempt to work around that error. I think this holds even in the case of
ill-formed XML (the spec says you must report an error, not how that error
must be reported).

In that specific case of ill-formed XML I believe the spec'd

behaviour

Post by Danny Ayers
is for the parser to stop dead in its tracks. XML isn't robust in the
Postel sense, though an app using it may be. But I've been through the
mill a lot of times on this on the Atom list, mostly arguing from the
more Draconian point of view. At this stage in the game, I can't see
any developer of existing (popular aggregator) tools making their
input section respond by rejecting the data altogether. If the spec
says it's a no-no, I reckon it'll be widely ignored, if the spec says
it's ok, new developers will be as liberal as the old. So as a
realistic compromise I suppose a very clear error message SHOULD be
given (maybe with the opportunity to manually notify etc etc), or the
app MAY just ditch the stuff altogether.
Cheers,
Danny.
--
http://dannyayers.com

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Danny Ayers]

Post by ecomputerd
It is very unlikely that a popular aggregator would reject invalid
RSS altogether. If any aggregator is able to read the feed, one of
the first things the developer will hear is "I can read the feed
with YYY reader, why not yours?" This has been my experience.

Yep, this was (IMHO) the strongest argument against error-only
reporting of ill-formed XML in Atom.

I still think had there being a will within the developer community to
insist on rejecting bad XML as a general rule, then the feedback
effect would have meant that the proportion of non-XML feeds would
have declined sufficiently for "I can read YYY" having been so
marginal as to avoid proliferation of liberal parsers.

This would only have been viable with Atom because it was effectively
starting from day zero. Even then many developers will be extending
existing (liberal) parsers rather than building anew. The approach
wouldn't stand a chance with "simple" RSS, or probably for that matter
with RSS 1.01. Whether it's appropriate for 1.1 I don't know, but
given the attitudes of people in the Atom WG (a more spec-respecting
bunch than average) I suspect the display-but-shout-loud approach to
ill-formed XML is probably most appropriate for RSS 1.1.

One thing that is sure, having a well-known online validator and tests
early on encouraged spec conformity among (0.3 beta) early-adopters. I
would imagine this will be doubly important with RSS 1.1, where the
validity of RDF/XML is also an issue.

Just a thought, if the normative spec is say OWL Lite, then what
happens with modules which e.g. use >1 cardinality?

Cheers,
Danny.
--
http://dannyayers.com



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

Post by ecomputerd
It is very unlikely that a popular aggregator would reject invalid
RSS altogether. If any aggregator is able to read the feed, one of
the first things the developer will hear is "I can read the feed
with YYY reader, why not yours?" This has been my experience.

Then how about breaking the cycle? How about calling a halt to the
foolisness and focusing instead on actually fix the source of the problem,
the feed and it's creation tool? I'm sick and tired of developers whining
about the /possibilitly/ of users raising complaint as an excuse. It seems
far more energies are getting wasted on working around the bad data than it
would ever take to just deal with the sources and solve the problem
outright.

-Bill Kearney
Syndic8.com




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[ecomputerd]

Post by Bill Kearney

Post by ecomputerd
It is very unlikely that a popular aggregator would reject

invalid

Post by Bill Kearney

Post by ecomputerd
RSS altogether. If any aggregator is able to read the feed, one of
the first things the developer will hear is "I can read the feed
with YYY reader, why not yours?" This has been my experience.

Then how about breaking the cycle? How about calling a halt to the
foolisness and focusing instead on actually fix the source of the problem,
the feed and it's creation tool?

Because incorrectly reading feeds leads to users viewing your
aggregator as inferior.

Post by Bill Kearney
I'm sick and tired of developers whining
about the /possibilitly/ of users raising complaint as an excuse.

I understand that you are sick and tired of whining, but I wasn't
aware that I was whining. As I believe I mentioned, I speak from
*experience* not speculation.

Post by Bill Kearney
It seems
far more energies are getting wasted on working around the bad

data than it

Post by Bill Kearney
would ever take to just deal with the sources and solve the problem
outright.

I don't think this viewpoint takes into account the sphere of the
developers perceived influence. To "deal with the sources", an
aggregator developer would require additional communication and
persuasion, to as-yet-unknown developers, having an unknown outcome,
while modifying your own (aggregator) code is much more
straightforward, timely, with a much higher chance of success.

By your line of thinking, I don't understand why the producers of
the code don't guarantee correct generation of their XML. Why should
aggregator developers be saddled with the responsibility of ensuring
the validity of the producer developers' code? Especially when
rejecting slightly invalid code puts your application in a worse
light from the end users perspective. We developers are not one
aggregate (pun not intended).

We can go 'round and 'round with this argument. With my original
post, I was just pointing out the immediate reality of the
aggregator developer.

I would be happy to share with you, under an NDA, my XML processing
code if you will provide me with code that generates a flag letting
the higher levels of code know if the XML is invalid and in which
way.

For your reference, my code is in C# for the Compact Framework.

I suspect, but I'm not sure, that you might reject this as a less
valuable use of your time compared to your alternatives. That is the
same conclusion, with respect to my time, to which I have come.

With respect,

Greg Smith
Author, FeederReader - The Pocket PC RSS reader and podcatcher
www.FeederReader.com









Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Bill Kearney]

Pardon me if I seem too cranky about this. I'm perhaps dragging along the
considerable baggage of past RSS-DEV mailing list thread arguments regarding
the issues of what is or isn't "broken" and how they should or shouldn't be
dealt with.

The current state of the art is MUCH improved from those days. Vigilance
remains necessary as a great many new tools (and new developers) aren't
always up to speed on some of the historical problems and why they've been
resolved the way they are today. Certain blogging tools and language
tagging comes to mind...

Post by l***@public.gmane.org
I share your sentiment and also think that developers should take
standards compliance more seriously.

And stop wasting energies trying to twist Postel's intentions to support
lame arguments.

Post by l***@public.gmane.org
But what option did I have? To tell my customers that the 80% of web
pages they are viewing in their browser do not follow HTML standard
and we could not process them?

An RSS tool is not an HTML browser. The two do not compare. Unlike HTML,
RSS seeks to make great effort to separate data from presentation (encoded
HTML abominations aside). As such there really isn't all that much about
what the spec entails that tools can't rise up to support.

-Bill Kearney




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Dan Brickley]

Post by Bill Kearney

Post by Christopher Schmidt
Although I understand what you're saying with this statement, I would like
specifically, Blam!, which uses RSS.Net for parsing, supports RSS 1.1
feeds with no changes at all.

Let's be VERY careful here. It treads quite dangerously toward the problems
associated with coddling bad tools. That a given tool doesn't PROPERLY
throw errors on this 1.1 format is a BAD SIGN for that tool.

+1

danbri

ps. I'm one of the rss-dev listowners, since last year when Rael
gave me admin privs. Am happy to share this mixed blessing...



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kevin A. Burton]

Post by Christopher Schmidt
Although I understand what you're saying with this statement, I would like
specifically, Blam!, which uses RSS.Net for parsing, supports RSS 1.1
feeds with no changes at all.

Great for Blam... never heard of it though ;)

Anything that uses path based parsing won't support it. Anything that
just looks for 'items' anywhere in the DOM *might* support it.

My bet is that certainly over 10% of the parsers will fail now on RSS
1.1 but its probably more like >50%

Post by Christopher Schmidt

Post by Kevin A. Burton
If its
RSS 1.1 it should be backwards compatible at a MINIMUM with RSS 1.0.
An
RSS 1.0 parser should be able to parse RSS 1.1 or call it something
else. RSS 3.0 ....

RSS 3.0 is already taken, although in jest, by two different
specifications: Aaron Swartz's 3.0[1] and Dan Brickley's RSS 3.0, which
was at http://groups.yahoo.com/group/rss3 but seems to have been wiped
from the servers at some point. (The original message is still
available[2], however.) To use this name would confuse the syndication
issue even more than it already is, a problem which no one wants to
encourage, least of all Sean or I.

I realize... Use 3.14149

Post by Christopher Schmidt

Post by Kevin A. Burton
As an implementor I'll have to go through a lot of trouble to support
RSS 1.1 and I don't want to do it... Its not necessary.

And that's acceptable. We've outlined the Specification for review
by the community: that does not mean in any way that people are
required to implement it. There are probably no aggregators out there
which handle every format that there is,

Yes there is... Rojo ;)... The only Excepitons are RSS 3.0 and 1.1 ;-)

Post by Christopher Schmidt
and that's not a problem: if
people want to use a specific type of feed, they will use a tool which
supports it. Does it create somewhat of a mess? Yes, unfortunately,
but these things happen, and life goes on.
RSS 1.1 is not designed to force tool designers to do anything: our
goal was not to create a competitor to any syndication format. It was
primarily designed to fill the need for an improved version of RSS 1.0.

If a significant portion of the parsers don't support RSS 1.1 then its
not an improvement.

Post by Christopher Schmidt
Given the relatively small differences between RSS 1.0 and RSS 1.1, I
disagree that it is a complete revolution from RSS 1.0.
Most RSS 1.0-friendly aggregators will still have problems aggregating
RSS 0.9. There is no change small enough that you can maintain complete
backwards compatibility in all tools: We strove instead to make it
relatively simple for implementors to implement the changes we did choose
to make.

Implementors are only 1/2 of the equation. You can't forget about the
aggregators.

Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!

Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412



[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Reto Bachmann-Gmuer]

I have been experimenting on the possibility to fix bugs in RSS 1.0
while maintaining a higher degree of compatibility and without changing
the namespace.

The draft at http://esw.w3.org/topic/RSS deprecates several problematic
properties and introduces better alternatives, where possible the new
variants are superclasses of the old deprecated ones.

Additionally it addresses the problem that merging the triples of two
different versions of a RSS 1.0 causes incoherent rdf (multiple
properties of seq with the same ordinal-number).

I haven't used OWL in the schema but kept the changes to the current
version small. While some cardinality restrictions could be useful I
plead to be very conservative with this in order to facilitate future
usage scenarios.

reto

[Christopher Schmidt]

We are pleased to announce the publication of the second public draft
of the RSS 1.1 Specification, incorporating feedback received from the
syndication community:

http://inamidst.com/rss1.1/
- RSS 1.1: RDF Site Summary
(Preliminary Draft: 23rd January 2005)

The changes to the Specification are as follows. This list of
changes is also listed in Appendix B of the specification, Errata.

1. The RDF/XML version of the RDF Schema and OWL Ontology, ont.rdf,
is now the normative version instead of the Turtle version.
2. Encoding of documents has changed from having to be one of UTF-8,
UTF-16, or UTF-32 to allowing any encoding but recommending UTF-8.
3. Mentions of US-ASCII have been removed as redundant.
4. Use of RSS 0.92 as an example in the motivation section as been
changed to RSS 0.91.
5. All keyword MUSTs in section 4 have been changed to to musts.
6. The OWL cardinality constraints are now datatyped with
xsd:nonNegativeInteger.
7. All OWL qualified cardinality constraints have been split up.
8. rss:item/@rdf:about has been made mandatory.
9. :Image/:link is now optional in the RDF Schema and OWL ontology.
10. :URI is now an instance of owl:Class.
11. Cardinalities of 1 have been changed to minCardinality.
12. Introductory mention of "up-to-the-minute content" has been
changed to be less restrictive.
13. The RELAX NG compact schema now uses content groups for
reusability.
14. The erroneous grouping constraint, only noted in the changes
appendix, has been removed.
15. rss:image has been added as a property to the RDF Schema and OWL
ontology.
16. Leigh Dodds's status suggestion text has been incorporated.
17. The applicability of xml:base is now fully specified.
18. More information has been added on the semantics of
rss:item/rdf:about.
19. Attributes in no namespace are now disallowed in Any sections,
reflecting a constraint of RDF/XML.
20. A non-normative maching readable mappings to RSS 1.0 appendix has
been added.
21. The RDF Schema and OWL ontology now uses annotation properties.
22. The OWL Ontology is now in OWL Lite instead of OWL Full.

Any feedback on these changes or the specification in general can be
sent to the RSS-DEV mailing list, or directly to the authors. For
discussion of the RSS 1.1 Specification, there is also an IRC channel on
the Freenode[1] IRC network, #rss1.1.

RSS 1.1 is an independant draft and is not supported or endorsed in any
way by the RSS-Dev Working Group.

[1] http://freenode.net/
--
Christopher Schmidt



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Stephen Downes]

Hiya,

Without attending to the details of the specification, which I can see
from the discussion are in good hands, I would simply like to say that
RSS 1.1 is a significant improvement as a whole over 1.0 and has my support.

-- Stephen
--
---------------------.sig--------------------------
Stephen Downes ~ National Research Council Canada
http://www.downes.ca ~ stephen-***@public.gmane.org
---------------------------------------------------
The best daily online learning news and opinion:
OLDaily ~ http://www.downes.ca/news/OLDaily.htm
---------------------------------------------------




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Roy Flewelling]

Post by m***@public.gmane.org

Post by Ken MacLeod
Possibly better in any case would be to have the spec hosted
by the W3 as a Note as part of the Semantic Web Activity (I
don't think vocabularies should go the Rec route), assigning
the copyright to the W3.

I'm less inclined to support this notion if only to avoid adding yet another
layer to the process. It's not a 'bad idea' but not necessarily one that's
all that necessary IMHO.
-Bill Kearney

Submitting it as a W3C note might be helpful to communicate the work and
ideas -- but it doesn't do much beyond that.
--
Ian Graham
H: 416.769.2422 / W: 416.513.5656 / E:



Yahoo! Groups Links









__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Non-text portions of this message have been removed]







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
rss-dev-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/