-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Please reply to the rss-dev mailing list.

Permalink to this entry: http://www.peerfear.org/rss/permalink/1035934972.shtml

Around two months ago I published [1] a specification which provided a mechanism
for linking to external resources within an RSS (1.0) feed.

One common misconception is that RDF and RSS already provide link mechanisms.
The main difference with mod_link is that it provides a mechanism to provide
discovery of external resources by user agents without having to explicitly
enable new link types within an implementing application.

For example since it is known that the the given XML fragment is a link it is
possible to determine how that link should be handled within user agents.

Also, instead of just defining a way to represent links we also go ahead and
define new link relationships such as permalink [5], print [6], and service [7].

This enables some very compelling functionality:

- - provides runtime discovery for additional RDF (like FOAF [2])

This provides #include style functionality for RDF applications so that
agents do not have to fetch all resource every time an RSS channel has
changes but instead can use their own policy based on the type of link.

- - provides linkage to WSDL [3] services so that we can support runtime
discovery
of SOAP and XML-RPC providers.

Note that the current spec needs to do a better job documenting this
functionality. I am working on some more changes that I will have available
shortly.

- - provides the ability to link to additional RSS files to provide features
such
as alternative languages, alternative formats, commentary RSS feeds, etc.

The spec is very powerful if you take some time and think about it. If it
becomes successful I think it will really encourage a *lot* of innovation within
this area.

The only problem is that I have seen a less than encouraging adoption rate from
RSS aggregators. One reason is that two months is still a very short time
period and it is hard for developers to incorporate a complex spec within that
time. Another reasons is that we were in an RSS 1.0 vs. 2.0 civil war during
this time and this complicated the issue for developers.

This isn't bad in and of itself. I still have to improve documentation of the
spec (it is still in the proposal phase) and need to correct a few more issues.

The main problem is that I haven't been able to get any agreement with regard to
the actual XML encoding of the specification.

Since I was the main developer I made some design decisions which I felt were
appropriate. I didn't take advantage of RDF as I felt that it needed to remain
simple since it was such a core format. I only used *one* XML namespace for the
same reason.

I would like to officially receive commentary now with regard to the actual
representation of the format.

Below I have presented a list of options which I believe should capture the
feedback I have received from multiple people. If rss-dev developers would be
so kind as to give me a +1 on which path you believe we should take I would
appreciate it. Please only respond to the rss-dev mailing list.

Here is the list of options. Note that each has a set of pros and cons which
need to be considered before voting.

#1. Design a format that is simple above all else. Uses one namespace, don't
use RDF and keep the same "link" element for every link. Relationships are
provided with the 'rel' attribute.

This is the current path we are taking in the mod_link specification.

*Pros*

- Allows us to support any new link relationship

- Allows XML applications to easily discovery a link without having to
worry about much complexity. If it has uses the link namespace and a
link attribute name it is a link.

*Cons*

- Isn't RDF

- Requires a 'rel' attribute with an explicit URI namespace.

- Doesn't use XML namespaces to provide a URI predicate like the way RDF
does.

*Example*

<l:link l:rel="http://purl.org/rss/1.0/modules/link/#alternate"
l:type="application/rss+xml"
l:title="French"
l:lang="fr"
rdf:resource="http://www.example.org/index-fr.rss"/>

#2. Use a full RDF vocabulary for representing links.

This would use a base RDF schema and new links would be represented by
sub-classing a Link object.

*Pros*

- More modern spec and RDF compliant

- Provides a more elegant way to represent linkage

- Would have the advantage of having a base Link class that can be used
within other RDF applications and RSS modules.

*Cons*

- Requires RSS aggregators to use RDF Schema to support link discovery.

- Adds a number of namespaces (one per link type)

*Example*

Given a base RDF Schema class of Link an an Alternate class that
subclasses this:

<alt:alternate alt:type="application/rss+xml"
alt:title="French"
alt:lang="fr"
rdf:resource="http://www.example.org/index-fr.rss"/>

#3. Use the XLink [4] namespace with a base local attribute.

*Pros*

- Uses the standardized XLink namespace

- Would provide us with a lot more documentation

*Cons*

- Adds a duplicate namespace

- Slightly increases the verbosity of the spec as some XLink attributes
are going to be implicitly to RSS.

- XLink uses xlink:href for resource identification which means that our
RDF graphs will be different than if we would be using rdf:resource

- Would require us to use a 'link' element in our own namespace or
create new links per role.

*Example*

<l:link xlink:type="locator"
xlink:href="http://www.example.org/index-fr.rsss"
xlink:role="http://purl.org/rss/1.0/modules/link/#alternate"
xlink:title="French"/>

#4. Use one name per relationship and eliminate the 'link' local name.

*Pros*

- Very simple.

- Doesn't require an additional 'rel' link which can be troublesome.

- Similar to strategy #2 but does not use RDF

*Cons*

- Doesn't use URIs to provide the relationship so ad hoc relations are
not really supported.

*Example*

<alt:alternate alt:type="application/rss+xml"
alt:title="French"
alt:lang="fr"
rdf:resource="http://www.example.org/index-fr.rss"/>

1. http://web.resource.org/rss/1.0/modules/link/
2. http://www.google.com/search?q=FOAF
3. http://www.google.com/search?q=WSDL
4. http://www.w3.org/TR/xlink/
5. http://purl.org/rss/1.0/modules/proposed/link/#permalink
6. http://purl.org/rss/1.0/modules/proposed/link/#print
7. http://purl.org/rss/1.0/modules/proposed/link/#service

- --
Kevin A. Burton ( burton@..., burton@..., burton@...
)
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - burtonator@..., Web - http://www.peerfear.org/
GPG fingerprint: 4D20 40A0 C734 307E C7B4 DCAA 0303 3AC5 BD9D 7C4D
IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

The humans won't stop there! They'll make bigger boards with bigger nails and
so on. Pretty soon they will make a board with a nail in it so big it will
destroy them all!



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE9vx6mAwM6xb2dfE0RApQlAKC/ipuh3k8hMoS/8cvOsAs8oSaozgCgtKIU
wiqwmVy5vHPn3xB8V875MWw=
=Fr+o
-----END PGP SIGNATURE-----