[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: RSS Referencing



Sam Ruby wrote:
Aleksander Slominski wrote:
  
<atom:link href="" title="Foo">
<atom:link href="" title="Bar">
<atom:link rel="via" href="" title="other" />
<atom:link href="" class="moz-txt-link-rfc2396E" href="http://myspace/SomeTopic">"http://myspace/SomeTopic"/>
<s:link rel="s:topic" xmlns:s="my-space" href=""/>
    

Why is this superset necessary?  Atom supports decentralized definitions
of custom relations.

http://www.atomenabled.org/developers/syndication/#extensibility
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7.2

Here are a few examples of valid feeds:

http://feedvalidator.org/testcases/atom/4.1.1/link-rel-full.xml
http://feedvalidator.org/testcases/atom/4.2.7.2/absolute_rel.xml
http://feedvalidator.org/testcases/atom/6.4/link-extensions.xml

Note in the third example, there even are new attributes defined (in
their own namespace), and even elements placed inside the rel.

  
hi Sam,

thanks for the pointers - i think it is the best choice and i will use for ATOM 1.0 export even if it does not support a compact notation for multiple relations (such as in HTML4) which i think is used by some specs to express more in rel="..." such as XFN (none seems to support namespaces so some day "friend" rel is bind to collide with other "friend" ...) - example:

<a href="" class="moz-txt-link-rfc2396E" href="http://john">"http://john" rel="friend met colleague">John</a>.

which i think in ATOM 1.0 would be best expressed as an equivalent (but longer) set of links:

<atom:link rel="http://gmpg.org/xfn/rel/freind" href="" class="moz-txt-link-rfc2396E" href="http://john">"http://john" title="John"/>
<atom:link rel="http://gmpg.org/xfn/rel/met" href="" class="moz-txt-link-rfc2396E" href="http://john">"http://john" title="John"/>
<atom:link rel="http://gmpg.org/xfn/rel/colleague" href="" class="moz-txt-link-rfc2396E" href="http://john">"http://john" title="John"/>

this should work fine (especially that it can be autogenerated from XHTML content..)

the only thing i do not like is that i lost a separation between namespaces and term defined in that namespace (topic, tag, keyword, relation name etc.). in other words conversion of QName (pair of URI and name) into extended URI is not bidirectional in general (for example if i have URI: http://some/A#B - is term part "B", "A", or "A#B" even if '#' is illegal in NCName ...)

thanks,

alek
-- 
The best way to predict the future is to invent it - Alan Kay