Feb 27
IUSR毕业札记
没时间了，倒是回家时翻腾出高三时写过的一篇作文，摘上来，呵呵，留个纪念……
月下山上
半小时前我还认为说服自己三更半夜来这山上就像说服木乃伊微笑成蒙娜丽莎一样不可思议，而三十分钟后我坐在山顶，对着充电灯下的纸页发呆。
山很小，黄土堆成的，而且没有名字，或是有一个已被人遗忘了的名字：单这一个理由我就知道我可以被允许同病相怜地坐在它肩上，在这个深夜。
坐稳了，风很大。
我仔细地盯着月亮。今晚我才得以看到十八年来我亲见的最离奇的月亮：深红的月亮，慢慢下坠，尽管并不圆。在我印象中，月亮从来都是很体贴的，总能在我想看她时在天幕中描出一片皎洁，从没有过像今晚一般黯淡，如同没有落尽的夕阳，或是吁吁喘息的炭火。
我还记得两年前的中秋，也是在这山的这个地方，我抱着睡熟的小狗坐在一厚沓报纸上。那晚月亮在浓云中遁去了两个多小时，我就在西风中擦着鼻涕等了那么久，然后月亮满意地掀开云，回报给我从额头到脚下的皓白，也把身下暗黄的土山漂白成按比例缩小的喜玛拉雅。一刹那我认定世间的等待都有价值，就像席慕容的那句：如果你肯等待／所有漂浮不定的云彩／到了最后／终于都会汇成河流。
依旧是月色溶溶夜，现在这月亮却温存不再，我甚至可以想像它也有如太阳一般火热的心，或是无数等足五百年的凤凰涅槃时自焚的烈焰，所以能燃烧得这样唯美。
这不正常，可今夜我又找不出什么算作正常，所有的一切像极了一卷剪辑错了的胶片：深红坠落的月亮，为写篇文字跑来山上的高三学生，还有我刚刚察觉到的山上夏季的西北风。这样的异常，成就了今夜这样迷离的图案，犹如梵高的重彩画。
我坐在这里看着时间流过，冲动地想要继续等待日出。到时天上或许就真的会有两轮宁静的深红，而不是眼角眉梢一场误会。世间对日月的评价就可以一瞬间拨乱反正，人们可以见识到施与者与回馈者究竟谁是慷慨，三足乌与霜玉兔到底哪一个热忱，盘古明媚的左眼与清澈的右眼终究孰明孰暗。
好吧，我等。
毫无征兆地，我打了一个寒颤。我清楚自己又大煞风景不可救药地想起了一到七月七日就要请勿飞扬的那根指挥棒，任何不羁的灵魂都要被他搅得缠在一起打个死结。我承认想起它是今夜最最不和谐的一件事，然而却也是最最可以决定些什么的事。看来我无论如何不属于这里，不属于无名无姓的山，不属于深红精致的月，不属于凌晨两点的夜。与其让我者仍求名利的人打搅这幅迷离的夜中重彩画，不如就此把自己从画中摘下。
就这样我说服了自己离开。这远比说服自己到来容易，我也无法入静地守望天上的一切。
身旁的充电灯也暗了，我的确该离开了，带着我第一次于钢筋水泥之外写就的一纸文字。
今夜或许是潦草的，但我真心写过。
晚安，月亮。
Feb 26
IUSR毕业札记
写完这篇，我就得赶紧回家去了，爸妈又会准备一大堆好吃的等我回去消灭干净
可是一直以来，我都把回家看为一种莫大的负担，有时真的后悔自己为什么没有考到外地的大学，而进了这么一个让我觉得很讨厌很后悔的地方。有时玩计算机玩得兴起，却不得不回家去，让我感觉很沮丧，这种感觉久而久之潜移默化地改变了我的脾气，让我一想到家就觉得很沉重，而回家像是一种不可推卸的责任，我必须得完成这个一星期一次的任务，每次回到家，都好像父母欠了我什么一样，一不顺心也就发火，我想，也许我是急着回到宿舍打开计算机，继续被打断的事情。
其实，我的想法没错，哦，我是说“回家是一种责任”这个想法。父母年岁越来越大了，而且天天担心我的学习又让他们衰老得更快。我记得有一次，大概是SARS闹得正凶的那年，学校封闭了出口，妈便大老远从家坐车来给我和LP送吃的，还带了一些消毒用的医用醋酸，到了学校也没法进大门，只能隔着一人多高的铁门把东西一样一样地给我递进来。因为学校不让学生出校，所以我只好等到期末考试都结束了才回家，当时已经是初夏了，爸用摩托车送我回家，路过家门口时看见一个很熟悉的背影，很像妈妈，但却那么瘦小，我就以为是那些总在楼荫里乘凉的那些个老太太，可从存车处出来我才发现，那还真是我的妈妈……妈从小就很胖，身体很好，后来上了年纪，也知道肥胖对人健康不好了，可无论怎么减就是瘦不下去，她也说自己是“喝口凉水都会长肉”的人，可就那么一个学期，我发现她瘦了那么多，我都几乎要认不出来了……
爸刚出生的时候身体很差，小时候也爱被别人欺负，后来却喜欢上了练体操，身体也越来越好，和爸一起玩到大的那些叔叔伯伯们都说当时爸就像个健美运动员。可人是怎么也抵不住岁月的，爸曾经健康的体魄现在也每况愈下，虽然还是比相同年纪的人好得多，可干一些事的时候也已经力不从心了。每次我在家时，如果我在看书或者编着自己自以为是的程序时，爸无论干什么活都不会叫着我，他也总是说我干的是“正事”，叫妈也不要打搅我。最近爸的身体倒是越来越差了，自从自己修理摩托车时第一次闪了腰，就好像落下病根一样，哪怕干再轻松的事，只要不注意，腰就可能受伤。上次看着爸趴在床上让妈在腰上贴药膏的时候，我TM竟然才意识到，爸也老了，这个家现在开始需要我为爸分担以前的负担了……
怎么说呢，呵呵，后来我找工作也不想去找那些外地的工作了，因为我得留在家里替爸妈分担家务，要天天回家让他们放心。所有的这些被我曾视为负担的事情现在都是我的权利，是我义不容辞的。
可能会有N个人说“你这孩子怎么一直这么不懂事呢”，是啊，我一直不懂事，以至于让父母担惊受怕似的度过这四年。我在计算机前挥霍着我的青春，干着有意义或没有意义的事，却从来也没有想到过在同一个城市的我的家里，我那早已开始变老的父母还是很希望我能马上回到家里。也许对于他们而言，虽然我是在这个城市上学，离他们很近，但同时我又是他们挂念着的游子，离他们很远……
时间刚刚好，收拾一下我就要回家了
我敢打赌，元宵节时家里第一次吃的鱼翅，妈一定还放在冰箱里舍不得吃，只等我今天回去，全家人一起分享……
Feb 25
IUSR毕业札记
从小到大，撒谎是若干几件不用别人教我我就会的事情之一，对此我倒没有感觉无师自通的自豪，只有深深的不安。从来看到的有关星座方面的书都会说，金牛座的人说谎是很容易看出来的、还没开始说谎就脸红脖子粗云云，我算是克服了金牛在这方面的弱项，就算青出于蓝而胜于蓝了。
英语里有一种lie听上去就很美好：white lies，哇，白色的，听上去很纯很美。后来又有个电影，”The True Lies”，我在这部戏里算是见识到施瓦星格笑起来到底啥模样的了，也明白了说谎不一定都是恶意，说谎也不像想像中那么可憎可恶。
小的时候撒的谎现在想起来都可笑，比如没写作业、花钱买水贴之类的。自从上了大学，我的谎越撒越勤快，小到比如，呃，那天一个网友让我给她的照片在某个网站上评分，我说“我这里打不开那个网页”，其实当时我正refactor着手下的一个程序，大抵像我这么臭屁的人忙活时被人打断心里都是很不舒服的，于是一句谎话过去，至少我清静了一会儿，不过后来还是去给人家评分，一是忙完了，二是人家是我学会上网之后第一个网友。
大一点儿的谎话大概都和学习有关。妈妈总是说我上了大学没让他们老两口子省心反而更费心了，这当然不是说我的个人问题迟迟得不到解决或是不会和周围的同学和平共处，而实在是因为我的那点儿成绩让他们天天如履薄冰。我知道自己不孝极了，让他们整天为我这点儿破事儿操心劳神的，可一坐在计算机前面确实就管不住自己了，宁可整理一下午email也决不主动看哪怕一页书。我坚信自己是为计算机而生的，初一时第一眼看到那台老旧的灰白单显的486我就想这辈子都要搞计算机，高三时对生物比较在行，还差点儿就去学生物了，结果如愿以偿地进了喜欢的计算机系，后来才逐步发现这个错误犯得过头了…呃，跑题跑得也过头了…大一第一学期就挂了两门，加一起10个学分，重修费也得500块钱呢，然后下学期又是一门，我不敢面对爸妈充满希望的眼神，就告诉他们说全都pass了，然后自己勒紧裤腰带去交重修费。
再后来，呃，我也知道自己不上课在学校是终究会有混不下去的一天的——试读了…我也想瞒着父母，可这次不行，这可不是小事儿，按人家的说法，“学校得对你们负责”，“哪天突然退学了家里怎么接受”。我现在都还记得妈得知这个消息时伤心成什么样子……
试读再有不及格可就得退学了。呵呵，既然我还坐在这儿有一搭没一搭地更新我这自娱自乐的blog，就说明我撑过了那一年恶心的日子。可毕竟是试读，不敢乱选课乱考试，所以修的学分比学校安排的都要少一些，越积越多，过了那一年，虽然努力了几个学期，但仍旧落下一些，这些积压到今天的一分一分又一分，让我只好看着同学们高高兴兴地走出这个该死的学校，而自己只能强忍着恶心再上一年……
即便如此，我还是跟父母瞒下了9个学分，这样他们或许过得会更好一些，哈哈，我姑且这么认为吧……
撒谎也不都是那么管用的，尤其现在通讯技术这么发达，一个电话打回家，后果不堪设想……
其实我倒不怕谎话穿帮，本来我也没想过要瞒天过海一辈子，就像当初高考过后录取通知书发完，我把自己从高一到高三做过的那些爸妈不敢想像的事情都跟他们一五一十的像讲故事一样说了个遍，以表明自己心里有数知道锅是铁打的什么是最重要的等等。我始终觉得，说谎不一定就是可耻的，可耻的是不知道自己为什么要说谎。
我说谎过后最怕LP追查，她查我也很方便，只消要我发一个誓，而且发誓时肯定是要说“如果我说谎就让我和LP分手”，这比什么“天打五雷轰”要实际得多，也更让我有所顾忌，所以我的谎话就瞒不过去她。
我总怕自己说谎说成习惯，真的成了自己所不齿的不知道为什么要说谎的那类人，所以我决定真的该用心学习了，至少我现在说谎有99%是因为学习
还有，今天刚知道，学校重修费涨钱了，忍不住要骂那句非常有特色的MLGBZD，因为我自己瞒下的那9个学分现在马上就要升值了
Feb 24
IUSR他山之石
骂得好，早就感觉这个一直自吹自擂地网站有些过了。嘿嘿，备份在这里，趁最近还能看到:P
2005-2-23 15:53:12 (未注册网友) 61.182.161.*
博客中国的本质
一定得选最热门的话题
雇著名的骂人泼妇
全包装成资深评论家
每个泼妇都有资深的经历
简历最少也得四百个字
什么科技、新知、生活、教育，能想到的全部分类
网站里有专题，到处有广告，首页一堆flash
大红色，特喜庆的那种
网民一进来，甭管真的假的都得跟人家说
全球博客第一门户
一副恬不知耻的无赖嘴脸
倍儿满足
网站里搞一堆名人博客
网名就用他们的真实姓名
写这些博客的编辑就几十个
再建一个博客论坛，什么都有
就是一个字儿——乱
想找个帖子就得花几个小时
专题里不是捧臭脚就是下井石，你想踏踏实实谈点东西呀
根本找不到门口在哪里
你说这样的网站，得卖多少钱？
我觉得怎么着也得两千万美金吧
两千万美金？！
那是枪手们的工资！
四千万美金起！
你还别嫌贵，还不打折！
你得研究方兴东办网站的心理
靠骂微软捧红自己的主，网站根本就是勒索和献媚的工具
什么叫IT强盗你知道吗？
IT强盗就是给我钱我就捧你，不给钱我就灭你
所以，博客中国口号要改成
炒做自己，勒索别人！
Feb 22
IUSR毕业札记
札记而已。
如果我能写一些很好的文章，记录我毕业前在校的点点滴滴，我会很高兴。里面也许会有很多值得回忆的事情：工作落实，和一起进校的同学们在一起吃散伙饭，帮外地的同学搬箱子赶火车，送别时不知道会不会掉下来的眼泪……
可很遗憾，没错，遗憾，就像那谁说的，人生就是由一个一个的遗憾组成的。
毕业，也许明年的这个时候我会继续憧憬着它，因为到时候就如一个朋友所说：“没事，出了校门就是咱们的天下了”……
谨以此开题，为我即将迟到的毕业做一个幸灾乐祸的墓志铭。
Feb 22
IUSR规范参考
摘抄自 http://blogs.law.harvard.edu/tech/rss
Contents
What is RSS?
Sample files
About this document
Required channel elements
Optional channel elements
Elements of
Comments
Extending RSS
Roadmap
License and authorship What is RSS? RSS is a Web content syndication format.Its name is an acronym for Really Simple Syndication.RSS is a dialect of XML. All RSS files must conform to the XML 1.0 specification, as published on the World Wide Web Consortium (W3C) website.A summary of RSS version history.At the top level, a RSS document is a element, with a mandatory attribute called version, that specifies the version of RSS that the document conforms to. If it conforms to this specification, the version attribute must be 2.0. Subordinate to the element is a single element, which contains information about the channel (metadata) and its contents. Sample files Here are sample files for: RSS 0.91, 0.92 and 2.0.Note that the sample files may point to documents and services that no longer exist. The 0.91 sample was created when the 0.91 docs were written. Maintaining a trail of samples seems like a good idea.About this document This document represents the status of RSS as of the Fall of 2002, version 2.0.1. It incorporates all changes and additions, starting with the basic spec for RSS 0.91 (June 2000) and includes new features introduced in RSS 0.92 (December 2000) and RSS 0.94 (August 2002). Change notes are here.First we document the required and optional sub-elements of ; and then document the sub-elements of . The final sections answer frequently asked questions, and provide a roadmap for future evolution, and guidelines for extending RSS.Required channel elements Here’s a list of the required channel elements, each with a brief description, an example, and where available, a pointer to a more complete description.
Element
Description
Example
title
The name of the channel. It’s how people refer to your service. If you have an HTML website that contains the same information as your RSS file, the title of your channel should be the same as the title of your website.
GoUpstate.com News Headlines
link
The URL to the HTML website corresponding to the channel.
http://www.goupstate.com/
description
Phrase or sentence describing the channel.
The latest news from GoUpstate.com, a Spartanburg Herald-Journal Web site.Optional channel elements Here’s a list of optional channel elements.
Element
Description
Example
language
The language the channel is written in. This allows aggregators to group all Italian language sites, for example, on a single page. A list of allowable values for this element, as provided by Netscape, is here. You may also use values defined by the W3C.
en-us
copyright
Copyright notice for content in the channel.
Copyright 2002, Spartanburg Herald-Journal
managingEditor
Email address for person responsible for editorial content.
geo@herald.com (George Matesky)
webMaster
Email address for person responsible for technical issues relating to channel.
betty@herald.com (Betty Guernsey)
pubDate
The publication date for the content in the channel. For example, the New York Times publishes on a daily basis, the publication date flips once every 24 hours. That’s when the pubDate of the channel changes. All date-times in RSS conform to the Date and Time Specification of RFC 822, with the exception that the year may be expressed with two characters or four characters (four preferred).
Sat, 07 Sep 2002 00:00:01 GMT
lastBuildDate
The last time the content of the channel changed.
Sat, 07 Sep 2002 09:42:31 GMT
category
Specify one or more categories that the channel belongs to. Follows the same rules as the -level category element. More info.
Newspapers
generator
A string indicating the program used to generate the channel.
MightyInHouse Content System v2.3
docs
A URL that points to the documentation for the format used in the RSS file. It’s probably a pointer to this page. It’s for people who might stumble across an RSS file on a Web server 25 years from now and wonder what it is.
http://blogs.law.harvard.edu/tech/rss
cloud
Allows processes to register with a cloud to be notified of updates to the channel, implementing a lightweight publish-subscribe protocol for RSS feeds. More info here.
ttl
ttl stands for time to live. It’s a number of minutes that indicates how long a channel can be cached before refreshing from the source. More info here.
60
image
Specifies a GIF, JPEG or PNG image that can be displayed with the channel. More info here.
rating
The PICS rating for the channel.
textInput
Specifies a text input box that can be displayed with the channel. More info here.
skipHours
A hint for aggregators telling them which hours they can skip. More info here.
skipDays
A hint for aggregators telling them which days they can skip. More info here.
sub-element of is an optional sub-element of , which contains three required and three optional sub-elements.is the URL of a GIF, JPEG or PNG image that represents the channel.
Feb 22
IUSR规范参考
RDF Site Summary (RSS) 1.0
Abstract
RDF Site Summary (RSS) is a lightweight multipurpose extensible metadata description and syndication format. RSS is an XML application, conforms to the W3C”s RDF Specification and is extensible via XML-namespace and/or RDF based modularization.
Authors
The members of the RSS-DEV Working Group:
Gabe Beged-Dov, JFinity Systems LLC
Dan Brickley, ILRT
Rael Dornfest, O”Reilly & Associates
Ian Davis, Calaba, Ltd.
Leigh Dodds, xmlhack
Jonathan Eisenzopf, Whirlwind Interactive
David Galbraith, Moreover.com
R.V. Guha, guha.com
Ken MacLeod, (Independent)
Eric Miller, Online Computer Library Center, Inc.
Aaron Swartz, The Info Network
Eric van der Vlist, Dyomedea
Version
Latest Version: http://purl.org/rss/1.0/spec
1.3.4 2001-05-30 Fixed small typo in section 5.3.6 (as, announcement)
1.3.3 2001-03-20 Updated mime-type and URI (as, announcement)
1.3.2 2000-12-19 (Changed style and tidied markup; revisions author: SBP)
1.3.1 2000-12-17 (Typo correction: An upper limit of 15 items per RSS document is recommended, not enforced [5.5].)
1.3 2000-12-09
Status
Release
Comments should be directed to the RSS-DEV mailing list, archived at http://www.egroups.com/messages/rss-dev.
Rights
Copyright ? 2000 by the Authors.
Permission to use, copy, modify and distribute the RDF Site Summary 1.0 Specification and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of the specification for any purpose. It is provided “as is” without expressed or implied warranty.
This copyright applies to the RDF Site Summary 1.0 Specification and accompanying documentation and does not extend to the RSS format itself.
Table of Contents
1. Introduction
2. Background
3. Motivation
4. Design Goals
4.1 Lightweight
4.2 Multipurpose
4.3 Extensible
4.4 Metadata
4.5 Syndication
5. Core Syntax
5.1 < ?xml version=”1.0″?>
5.2 <rdf :RDF>
5.3 <channel>
5.3.1 <title>
5.3.2 <link>
5.3.3 <description>
5.3.4 <image>
5.3.5 <items>
5.3.6 <textinput>
5.4 <image>
5.4.1 <title>
5.4.2 <url>
5.4.3 <link>
5.5 <item>
5.5.1 <title>
5.5.2 <link>
5.5.3 <description>
5.6 <textinput>
5.6.1 <title>
5.6.2 <description>
5.6.3 <name>
5.6.4 <link>
6. Modules
7. Examples
8. Resources
9. Acknowledgements
1. Introduction
RDF Site Summary (RSS) is a lightweight multipurpose extensible metadata description and syndication format. RSS is an XML application, conforming to the W3C”s RDF Specification. RSS is extensible via XML-namespace and/or RDF based modularization.
An RSS summary, at a minimum, is a document describing a “channel” consisting of URL-retrievable items. Each item consists of a title, link, and brief description. While items have traditionally been news headlines, RSS has seen much repurposing in its short existence. For sample RSS 1.0 documents, see the Examples section below.
2. Background
RSS 0.9 was introduced in 1999 by Netscape as a channel description framework / content-gathering mechanism for their My Netscape Network (MNN) portal. By providing a simple snapshot-in-a-document, web site producers acquired audience through the presence of their content on My Netscape.
A by-product of MNN”s work was RSS”s use as an XML-based lightweight syndication format, quickly becoming a viable alternative to ad hoc syndication systems and practical in many scenarios where heavyweight standards like ICE were overkill. And the repurposing didn”t stop at headline syndication; today”s RSS feeds carry an array of content types: news headlines, discussion forums, software announcements, and various bits of proprietary data.
RSS 0.91, re-dubbed “Rich Site Summary,” followed shortly on the heels of 0.9. It had dropped its roots in RDF and sported new elements from Userland”s scriptingNews format — most notably being a new item-level <description> element, bringing RSS into the (lightweight) content syndication arena.
While Netscape discontinued its RSS efforts, evangelism by Userland”s Dave Winer led to a groundswell of RSS-as-syndication-framework adoption. Inclusion of RSS 0.91 as one of the syndicaton formats for its Manila product and related EditThisPage.com service brought together the weblog and syndication worlds.
3. Motivation
As RSS continues to be re-purposed, aggregated, and categorized, the need for an enhanced metadata framework grows. Channel- and item-level title and description elements are being overloaded with metadata and HTML. Some producers are even resorting to inserting unofficial ad hoc elements (e.g., <category>, <date>, <author>) in an attempt to augment the sparse metadata facilities of RSS.
One proposed solution is the addition of more simple elements to the RSS core. This direction, while possibly being the simplest in the short run, sacrifices scalability and requires iterative modifications to the core format, adding requested and removing unused functionality. See Ian Davis”s RSS Survey (2000-07-25) for a more concrete representation of element usage.
A second solution, and the one adopted here, is the compartmentalization of specific functionality into the pluggable RSS modules. This is one of the approaches used in this specification: modularization is achieved by using XML Namespaces for partitioning vocabularies. Adding and removing RSS functionality is then just a matter of the inclusion of a particular set of modules best suited to the task at hand. No reworking of the RSS core is necessary.
Advanced applications of RSS are demanding richer respresentation of relationships between intra- and inter-channel elements (e.g. threaded discussions). RDF (Resource Description Framework) provides a framework for just such rich metadata modeling. RSS 0.9 provided a basic (albeit limited) RDF base upon which to layer further structure.
4. Design Goals
The RSS 1.0 design goal is an XML-based lightweight multipurpose extensible metadata description and syndication format. Backward compatibility with RSS 0.9 is a goal for ease of adoption by existing syndicated content producers.
4.1 Lightweight
Much of RSS”s success stems from the fact that it is simply an XML document rather than a full syndication framework such as XMLNews and ICE.
The following is a basic sample RSS 1.0 document, making use of only the core RSS 1.0 element set.
< ?xml version=”1.0″?>
<rdf :RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns=”http://purl.org/rss/1.0/”
>
<channel rdf:about=”http://www.xml.com/xml/news.rss”>
<title>XML.com</title>
<link>http://xml.com/pub</link>
<description>
XML.com features a rich mix of information and services
for the XML community.
</description>
<image rdf:resource=”http://xml.com/universal/images/xml_tiny.gif” />
<items>
<rdf :Seq>
<rdf :li resource=”http://xml.com/pub/2000/08/09/xslt/xslt.html” />
<rdf :li resource=”http://xml.com/pub/2000/08/09/rdfdb/index.html” />
</rdf>
</items>
</channel>
<image rdf:about=”http://xml.com/universal/images/xml_tiny.gif”>
<title>XML.com</title>
<link>http://www.xml.com</link>
<url>http://xml.com/universal/images/xml_tiny.gif</url>
</image>
<item rdf:about=”http://xml.com/pub/2000/08/09/xslt/xslt.html”>
<title>Processing Inclusions with XSLT</title>
<link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
<description>
Processing document inclusions with general XML tools can be
problematic. This article proposes a way of preserving inclusion
information through SAX-based processing.
</description>
</item>
<item rdf:about=”http://xml.com/pub/2000/08/09/rdfdb/index.html”>
<title>Putting RDF to Work</title>
<link>http://xml.com/pub/2000/08/09/rdfdb/index.html</link>
<description>
Tool and API support for the Resource Description Framework
is slowly coming of age. Edd Dumbill takes a look at RDFDB,
one of the most exciting new RDF toolkits.
</description>
</item>
</rdf>
4.2 Multipurpose
The 12 months since version 0.91 was released have seen the surfacing of various novel uses for RSS. RSS is being called upon to evolve with growing application needs: aggregation, discussion threads, job listings, homes for sale (multiple listings services), sports scores, document cataloging, etc. Via XML-namespace based modularization and RDF, RSS 1.0 builds a framework for both standardized and ad hoc re-purposing.
4.3 Extensible
The crux of the difference between RSS 1.0 and earlier (or lateral) versions lies in its extensibility via XML Namespaces and RDF (Resource Description Framework) compliance.
Namespace-based modules allow compartmentalized extensibility. This allows RSS to be extended:
* without need of iterative rewrites of the core specification
* without need of consensus on each and every element
* without bloating RSS with elements the majority of which won”t be used in any particular arena or application
* without naming collisions
RSS modules are covered in more detail in the modules section below.
4.4 Metadata
Metadata is data about data. While there is no dearth of information floating about the Web, there is precious little description thereof. The W3C”s Metadata Activity Statement has this to say on the subject:
The possible uses of the Web seem endless, but there the technology is missing a crucial piece. Missing is a part of the Web which contains information about information – labeling, cataloging and descriptive information structured in such a way that allows Web pages to be properly searched and processed in particular by computer.
RDF allows for representation of rich metadata relationships beyond what is possible with earlier flat-structured RSS. The existing RDF base in RSS 0.9 was the reason for choosing to build on the earlier version of RSS; attempting to re-introduce RDF into RSS version 0.91 proved a “putting the toothpaste back into the tube” proposition.
4.5 Syndication
Syndication is here defined as making data available online for retrieval and further transmission, aggregation, or online publication. The specifics of the various intricacies of syndication systems (free vs. subscription, push vs. pull, etc.) is beyond the scope of this specification.
5. Core Syntax
The core of RSS 1.0 is built upon RSS 0.9. RSS 1.0”s focus is on extensibility through XML-namespaces and RDF whilst maintaining backward compatibility.
Backward Compatibility with RSS 0.9
Backward compatibility is accomplished by the assumption and stipulation that basic RSS parsers, modules, and libraries ignore what they weren”t designed to understand:
1. Attributes; RSS 0.9 has no attributes outside of the RDF namespace declarations.
2. Element members of modularized extensions residing outside the default namespace.
3. Ad-hoc elements that don”t interfere with the overall structure of the RSS 0.9 document.
Extensibility via XML Namespace-Based Modularization
RSS 1.0 is extensible through XML-namespace based modules. While ad hoc extensibility is of course encouraged, it is hoped that a core set of agreed-upon modules covering such functionality as taxonomy, aggregation, Dublin Core, etc will emerge. See the Modules section below, as well as the registry of core RSS 1.0 Modules.
One restriction imposed on sub-elements of top-level channel, image, item, and textinput elements [5.3 <channel>, 5.4 <image>, 5.5 <item>, 5.6 <textinput>] is that these elements may not contain repeating sub-elements (e.g. <item><dc :subject /><dc :subject /></item>). This proposal only constrains the immediate sub-elements. Any further depth (of rich content or repeated elements) is already well-defined using RDF syntax.
RDF
RSS 1.0 builds on the fledgling RDF framework found in RSS 0.9 (and lost in RSS 0.91) via the following minimal additions:
* Each second-level element (channel, image, item, and textinput) must include an rdf:about attribute 5.3, 5.4, 5.5, 5.6 ].
* A channel-level RDF table of contents associating the image, items, and textinput with the channel at hand: [5.3.4 <image>, 5.3.5 <items>, 5.3.6 <textinput>]
In order to keep the RDF and plain XML views of RSS 1.0 in synch as much as possible, RSS 1.0 only supports usage of typed-element RDF syntax in the core elements.
Mime Type
The current mime-type recommendation for an RSS 1.0 document is application/xml. However, work is currently being done to register a mime-type for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used once it has been registered.
File Extension
A specific file-extension for an RSS 1.0 document is not required. Either .rdf or .xml is recommended, the former being preferred.
Encoding
While RSS 0.9 supported only ASCII encoding, RSS 1.0 assumes UTF-8. Using US-ASCII (i.e. encoding all characters over 127 as &#nnn;) is conformant with UTF-8 (and ISO-8859-1, HTTP”s default header encoding).
URLs
As a measure to assure backward compatibility with RSS 0.9, only the following schemes are acceptable in url and link elements: http:, https:, ftp:. mailto: is acceptable in the textinput”s link element only.
Entities:
XML reserves certain characters for markup. In order to include these in an RSS document, they must be replaced by their entity reference:
* < becomes <
* > becomes >
* & becomes &
The following two entity references are also recognized by conforming XML parsers. While common, their use is optional. They are, however, required when including a quote character in a string quoted using the same character; e.g. “”Hello,” she said” should be encoded as “"Hello," she said”.
* ” becomes '
* ” becomes "
Note: Since RSS 1.0 does not require a DTD, be sure to include inline declarations of entities used aside from the aforementioned five. The following DTD fragments are very useful as a source of HTML-compatible entities.
* http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
* http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent
* http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
Usage example:
< ?xml version=”1.0″?>
< !DOCTYPE rdf:RDF [
<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">
%HTMLlat1;
]>
<rdf :RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns=”http://purl.org/rss/1.0/”
>
…
Content Length:
While RSS 1.0 leaves acceptable content length for elements such as title, link, and description to the application, RSS 0.9”s maximum character lengths are deprecated to a status of suggested good practice for strict adherence to backward compatibility.
Notation:
In the following core element descriptions, the following notation is used:
* {something} is simply a placeholder for a URI, value, etc.
* While, in model descriptions a DTD-like syntax is used, this is for presentation purposes only and does not imply order. Element order is not important.
* In Model descriptions, ? signifies that an element or attribute is optional.
* In Model descriptions, + means “one or more” instances of this element or attribute is allowed.
* In Model descriptions, * means “zero or more” instances of this element or attribute is allowed.
5.1 < ?xml version=”1.0″?>
As an XML application, an RSS document is not required to begin with an XML declaration. As a best practice suggestion and to further ensure backward compatibility with RSS 0.9 (the specification for 0.9 required it), this specification recommends doing so.
Syntax: < ?xml version=”1.0″?>
Requirement: Optional (unless specifying encoding)
5.2 </rdf><rdf :RDF>
The outermost level in every RSS 1.0 compliant document is the RDF element. The opening RDF tag assocaties the rdf: namespace prefix with the RDF syntax schema and establishes the RSS 1.0 schema as the default namespace for the document.
While any valid namespace prefix may be used, document creators are advised to consider “rdf:” normative. Those wishing to be strictly backward-compatible with RSS 0.9 must use “rdf:”.
Syntax: </rdf><rdf :RDF xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns=”http://purl.org/rss/1.0/”>
Requirement: Required exactly as shown, aside from any additional namespace declarations
Model: (channel, image?, item+, textinput?)
5.3 <channel>
The channel element contains metadata describing the channel itself, including a title, brief description, and URL link to the described resource (the channel provider”s home page, for instance). The {resource} URL of the channel element”s rdf:about attribute must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the channel. Most commonly, this is either the URL of the homepage being described or a URL where the RSS file can be found.
Syntax: </channel><channel rdf:about=”{resource}”>
Requirement: Required
Required Attribute(s): rdf:about
Model: (title, link, description, image?, items, textinput?)
Example:
</channel><channel rdf:about=”http://www.xml.com/xml/news.rss”>
<title>XML.com</title>
<link>http://xml.com/pub</link>
<description>
XML.com features a rich mix of information and services
for the XML community.
</description>
<image rdf:resource=”http://xml.com/universal/images/xml_tiny.gif” />
<items>
<rdf :Seq>
<rdf :li resource=”http://xml.com/pub/2000/08/09/xslt/xslt.html” />
<rdf :li resource=”http://xml.com/pub/2000/08/09/rdfdb/index.html” />
</rdf>
</items>
<textinput rdf:resource=”http://search.xml.com” />
</channel>
5.3.1 <title>
A descriptive title for the channel.
Syntax: </title><title>{channel_title}</title>
Requirement: Required
Model: (#PCDATA)
(Suggested) Maximum Length: 40 (characters)
5.3.2 <link>
The URL to which an HTML rendering of the channel title will link, commonly the parent site”s home or news page.
Syntax: </link><link>{channel_link}</link>
Requirement: Required
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.3.3 <description>
A brief description of the channel”s content, function, source, etc.
Syntax: </description><description>{channel_description}</description>
Requirement: Required
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.3.4 <image>
Establishes an RDF association between the optional image element [5.4] and this particular RSS channel. The rdf:resource”s {image_uri} must be the same as the image element”s rdf:about {image_uri}.
Syntax: <image rdf:resource=”{image_uri}” />
Requirement: Required only if image element present
Model: Empty
5.3.5 <items>
An RDF table of contents, associating the document”s items [5.5] with this particular RSS channel. Each item”s rdf:resource {item_uri} must be the same as the associated item element”s rdf:about {item_uri}.
An RDF Seq (sequence) is used to contain all the items rather than an RDF Bag to denote item order for rendering and reconstruction.
Note that items appearing in the document but not as members of the channel level items sequence are likely to be discarded by RDF parsers.
Syntax: </items><items><rdf :Seq><rdf :li resource=”{item_uri}” /> … </rdf></items>
Requirement: Required
5.3.6 <textinput>
Establishes an RDF association between the optional textinput element [5.6] and this particular RSS channel. The {textinput_uri} rdf:resource must be the same as the textinput element”s rdf:about {textinput_uri}.
Syntax: <textinput rdf:resource=”{textinput_uri}” />
Requirement: Required only if texinput element present
Model: Empty
5.4 <image>
An image to be associated with an HTML rendering of the channel. This image should be of a format supported by the majority of Web browsers. While the later 0.91 specification allowed for a width of 1-144 and height of 1-400, convention (and the 0.9 specification) dictate 88×31.
Syntax: </image><image rdf:about=”{image_uri}”>
Requirement: Optional; if present, must also be present in channel element [5.3.4]
Required Attribute(s): rdf:about
Model: (title, url, link)
Example:
</image><image rdf:about=”http://xml.com/universal/images/xml_tiny.gif”>
<title>XML.com</title>
<link>http://www.xml.com</link>
<url>http://xml.com/universal/images/xml_tiny.gif</url>
</image>
5.4.1 <title>
The alternative text (“alt” attribute) associated with the channel”s image tag when rendered as HTML.
Syntax: </title><title>{image_alt_text}</title>
Requirement: Required if the image element is present
Model: (#PCDATA)
(Suggested) Maximum Length: 40
5.4.2 <url>
The URL of the image to used in the “src” attribute of the channel”s image tag when rendered as HTML.
Syntax: </url><url>{image_url}</url>
Requirement: Required if the image element is present
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.4.3 <link>
The URL to which an HTML rendering of the channel image will link. This, as with the channel”s title link, is commonly the parent site”s home or news page.
Syntax: </link><link>{image_link}</link>
Requirement: Required if the image element is present
Model: (#PCDATA)
Member of: image
(Suggested) Maximum Length: 500
5.5 <item>
While commonly a news headline, with RSS 1.0”s modular extensibility, this can be just about anything: discussion posting, job listing, software patch — any object with a URI. There may be a minimum of one item per RSS document. While RSS 1.0 does not enforce an upper limit, for backward compatibility with RSS 0.9 and 0.91, a maximum of fifteen items is recommended.
{item_uri} must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the item. {item_uri} should be identical to the value of the <link> sub-element of the <item> element, if possible.
Syntax: </item><item rdf:about=”{item_uri}”>
Requirement: >= 1
Recommendation (for backward compatibility with 0.9x): 1-15
Required Attribute(s): rdf:about
Model: (title, link, description?)
Example:
</item><item rdf:about=”http://xml.com/pub/2000/08/09/xslt/xslt.html”>
<title>Processing Inclusions with XSLT</title>
<link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
<description>
Processing document inclusions with general XML tools can be
problematic. This article proposes a way of preserving inclusion
information through SAX-based processing.
</description>
</item>
5.5.1 <title>
The item”s title.
Syntax: </title><title>{item_title}</title>
Requirement: Required
Model: (#PCDATA)
(Suggested) Maximum Length: 100
5.5.2 </link><link>
The item”s URL.
Syntax: </link><link>{item_link}</link>
Requirement: Required
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.5.3 <description>
A brief description/abstract of the item.
Syntax: </description><description>{item_description}</description>
Requirement: Optional
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.6 <textinput>
The textinput element affords a method for submitting form data to an arbitrary URL — usually located at the parent website. The form processor at the receiving end only is assumed to handle the HTTP GET method.
The field is typically used as a search box or subscription form — among others. While this is of some use when RSS documents are rendered as channels (see MNN) and accompanied by human readable title and description, the ambiguity in automatic determination of meaning of this overloaded element renders it otherwise not particularly useful. RSS 1.0 therefore suggests either deprecation or augmentation with some form of resource discovery of this element in future versions while maintaining it for backward compatiblity with RSS 0.9.
{textinput_uri} must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the textinput. {textinput_uri} should be identical to the value of the <link> sub-element of the <textinput> element, if possible.
Syntax: </textinput><textinput rdf:about=”{textinput_uri}”>
Requirement: Optional; if present, must also be present in channel element [5.3.6]
Required Attribute(s): rdf:about
Model: (title, description, name, link)
Example:
</textinput><textinput rdf:about=”http://search.xml.com”>
<title>Search XML.com</title>
<description>Search XML.com”s XML collection</description>
<name>s</name>
<link>http://search.xml.com</link>
</textinput>
5.6.1 <title>
A descriptive title for the textinput field. For example: “Subscribe” or “Search!”
Syntax: </title><title>{textinput_title}</title>
Description: Textinput title
Requirement: Required if textinput
Model: (#PCDATA)
(Suggested) Maximum Length: 40
5.6.2 <description>
A brief description of the textinput field”s purpose. For example: “Subscribe to our newsletter for…” or “Search our site”s archive of…”
Syntax: </description><description>{textinput_description}</description>
Requirement: Required if textinput
Model: (#PCDATA)
(Suggested) Maximum Length: 100
5.6.3 <name>
The text input field”s (variable) name.
Syntax: </name><name>{textinput_varname}</name>
Requirement: Required if textinput
Model: (#PCDATA)
(Suggested) Maximum Length: 500
5.6.4 </link><link>
The URL to which a textinput submission will be directed (using GET).
Syntax: </link><link>{textinput_action_url}</link>
Description: Textinput form action URL
Requirement: Required if textinput
Model: (#PCDATA)
(Suggested) Maximum Length: 500
6. Modules
Namespace-based modularization affords RSS 1.0 compartmentalized extensibility.
The only modules that ship “in the box” with RSS 1.0 are Dublin Core and Syndication, Consult the appropriate module documentation for further information.
Refer to RSS 1.0 Modules for module creation guidelines and registered core RSS 1.0 modules.
Some examples of module usage may be found in the Examples section below.
7. Examples
A basic RSS 1.0 (0.9-like) document, making use of only the core RSS 1.0 element set.
< ?xml version=”1.0″?>
<rdf :RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns=”http://purl.org/rss/1.0/”
>
<channel rdf:about=”http://www.xml.com/xml/news.rss”>
<title>XML.com</title>
<link>http://xml.com/pub</link>
<description>
XML.com features a rich mix of information and services
for the XML community.
</description>
<image rdf:resource=”http://xml.com/universal/images/xml_tiny.gif” />
<items>
<rdf :Seq>
<rdf :li resource=”http://xml.com/pub/2000/08/09/xslt/xslt.html” />
<rdf :li resource=”http://xml.com/pub/2000/08/09/rdfdb/index.html” />
</rdf>
</items>
<textinput rdf:resource=”http://search.xml.com” />
</channel>
<image rdf:about=”http://xml.com/universal/images/xml_tiny.gif”>
<title>XML.com</title>
<link>http://www.xml.com</link>
<url>http://xml.com/universal/images/xml_tiny.gif</url>
</image>
<item rdf:about=”http://xml.com/pub/2000/08/09/xslt/xslt.html”>
<title>Processing Inclusions with XSLT</title>
<link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
<description>
Processing document inclusions with general XML tools can be
problematic. This article proposes a way of preserving inclusion
information through SAX-based processing.
</description>
</item>
<item rdf:about=”http://xml.com/pub/2000/08/09/rdfdb/index.html”>
<title>Putting RDF to Work</title>
<link>http://xml.com/pub/2000/08/09/rdfdb/index.html</link>
<description>
Tool and API support for the Resource Description Framework
is slowly coming of age. Edd Dumbill takes a look at RDFDB,
one of the most exciting new RDF toolkits.
</description>
</item>
<textinput rdf:about=”http://search.xml.com”>
<title>Search XML.com</title>
<description>Search XML.com”s XML collection</description>
<name>s</name>
<link>http://search.xml.com</link>
</textinput>
</rdf>
An RSS 1.0 document pulling in elements from various modules (highlighted in different colours). Note: the modules in this example are for illustrative purposes only; refer to RSS 1.0 Modules for consummate module information.
< ?xml version=”1.0″ encoding=”utf-8″?> <rdf :RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:sy=”http://purl.org/rss/1.0/modules/syndication/”
xmlns:co=”http://purl.org/rss/1.0/modules/company/”
xmlns:ti=”http://purl.org/rss/1.0/modules/textinput/”
xmlns=”http://purl.org/rss/1.0/”
> <channel rdf:about=”http://meerkat.oreillynet.com/?_fl=rss1.0″>
<title>Meerkat</title>
<link>http://meerkat.oreillynet.com</link>
<description>Meerkat: An Open Wire Service</description>
<dc :publisher>The O”Reilly Network</dc>
<dc :creator>Rael Dornfest (mailto:rael@oreilly.com)</dc>
<dc :rights>Copyright © 2000 O”Reilly & Associates, Inc.</dc>
<dc :date>2000-01-01T12:00+00:00</dc>
<sy :updatePeriod>hourly</sy>
<sy :updateFrequency>2</sy>
<sy :updateBase>2000-01-01T12:00+00:00</sy>
<image rdf:resource=”http://meerkat.oreillynet.com/icons/meerkat-powered.jpg” />
<items>
<rdf :Seq>
<rdf :li resource=”http://c.moreover.com/click/here.pl?r123″ />
</rdf>
</items>
<textinput rdf:resource=”http://meerkat.oreillynet.com” />
</channel>
<image rdf:about=”http://meerkat.oreillynet.com/icons/meerkat-powered.jpg”>
<title>Meerkat Powered!</title>
<url>http://meerkat.oreillynet.com/icons/meerkat-powered.jpg</url>
<link>http://meerkat.oreillynet.com</link>
</image>
<item rdf:about=”http://c.moreover.com/click/here.pl?r123″>
<title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123</link>
<dc :description>
XML is placing increasingly heavy loads on the existing technical
infrastructure of the Internet.
</dc>
<dc :publisher>The O”Reilly Network</dc>
<dc :creator>Simon St.Laurent (mailto:simonstl@simonstl.com)</dc>
<dc :rights>Copyright © 2000 O”Reilly & Associates, Inc.</dc>
<dc :subject>XML</dc>
<co :name>XML.com</co>
<co :market>NASDAQ</co>
<co :symbol>XML</co>
</item> <textinput rdf:about=”http://meerkat.oreillynet.com”>
<title>Search Meerkat</title>
<description>Search Meerkat”s RSS Database…</description>
<name>s</name>
<link>http://meerkat.oreillynet.com/</link>
<ti :function>search</ti>
<ti :inputType>regex</ti>
</textinput>
</rdf>
8. Resources
* Background
o “RSS: Lightweight Web Syndication”
o XML Deviant: “RSS Modularization”
o “Will RSS Fork?”
* RSS
o Netscape”s RSS 0.9 Specification
o Netscape”s RSS 0.91 Specification
o Netscape”s RSS 0.91 Specification, Revision 3
o Netscape”s RSS/MNN Future Directions
o Userland”s RSS 0.91 Specification
o RSS Usage Survey (25 July 2000)
o xmlTree”s Directory of RSS channels
* RDF & Metadata
o Resource Description Framework (RDF)
o W3C Metadata Activity Statement
o RDFViz
* XML Namespaces
o Namespaces in XML
* Where to go for more…
o O”Reilly Network RSS DevCenter
o RSS Info — News and information on the RSS format
o “RSS 1.0: The New Syndication Format”
o xmlhack
o XMLfr
* Mailing Lists
o [RSS-DEV] Mailing List
o [Syndication] Mailing List
o [Alchemy] Mailing List
9. Acknowledgements
* The members of the [RSS-DEV], [Syndication] and [RSS] mailing lists for all their continued discussion and input
* The members of the My Netscape Network “Brooklyn” team for RSS 0.9 and 0.91 (Eckart Walther, Jeff Treuhaft, Wade Hennesey, Rafael Cedano, Bill Turpin, Dan Libby, and Mike Homer)
* James Carlyle
* Dale Dougherty
* Edd Dumbill
* Peter Wiggin
* Dave Winer
Feb 21
IUSR规范参考
Abstract
This specification describes version 0.3 of the Atom, an XML-based Web content and metadata syndication format.
Editorial Notes
This draft HAS NOT been submitted for publication, and does not have any status; it should be referred to as a “pre-draft.”
Discussion of this draft happens in two fora;
The Atom Syntax mailing list
The Atom Wiki Web site
Comments and suggestions can be directed to the mailing list, whilst active development happens on the Wiki.
Sections called out [[like this]] indicate editorial notes that should be removed before final publication.
RFC
TOC
Table of Contents
1 Introduction
1.1 Example
1.2 Conformance
1.3 Notational Conventions
2 Atom Documents
3 Common Atom Constructs
3.1 Content Constructs
3.1.1 “type” Attribute
3.1.2 “mode” Attribute
3.2 Person Constructs
3.2.1 “atom:name” Element
3.2.2 “atom:url” Element
3.2.3 “atom:email” Element
3.3 Date Constructs
3.4 Link Constructs
3.4.1 “rel” Attribute
3.4.2 “type” Attribute
3.4.3 “href” Attribute
3.4.4 “title” Attribute
4 The “atom:feed” Element
4.1 “version” Attribute
4.2 “xml:lang” Attribute
4.3 “atom:title” Element
4.4 “atom:link” Element
4.5 “atom:author” Element
4.6 “atom:contributor” Element
4.7 “atom:tagline” Element
4.8 “atom:id” Element
4.9 “atom:generator” Element
4.10 “atom:copyright” Element
4.11 “atom:info” Element
4.12 “atom:modified” Element
4.13 “atom:entry” Element
4.13.1 “atom:title” Element
4.13.2 “atom:link” Element
4.13.3 “atom:author” Element
4.13.4 “atom:contributor” Element
4.13.5 “atom:id” Element
4.13.6 “atom:modified” Element
4.13.7 “atom:issued” Element
4.13.8 “atom:created” Element
4.13.9 “atom:summary” Element
4.13.10 “atom:content” Element
5 Managing Feed State
6 Embedding Atom in Other Formats
7 Extending Atom
8 IANA Considerations
9 Security Considerations
§ References
§ Author”s Address
A Contributors
B Revision History
§ Full Copyright Statement
TOC
1 Introduction
Atom is an XML-based file format intended to allow lists of information, known as “feeds”, to be synchronised between publishers and consumers. Feeds are composed of a number of items, known as “entries”, each with an extensible set of attached metadata. For example, each entry has a title.
The primary use case that Atom addresses is for syndicating Web content such as Weblogs and news headlines to other Web sites and directly to consumers. However, nothing precludes it from being used for other purposes and types of content.
Details of comunication protocols between software agents using Atom are to be found in the Atom API specification <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</eref>.
[[ more motivation / design principles ]]
1.1 Example
A minimal, single-entry Atom feed serialized as XML 1.0:
< ?xml version=”1.0″ encoding=”utf-8″?>
<feed version=”0.3″ xmlns=”http://purl.org/atom/ns#”>
<title>dive into mark</title>
<link rel=”alternate” type=”text/html”
href=”http://diveintomark.org/”/>
<modified>2003-12-13T18:30:02Z</modified>
<author>
<name>Mark Pilgrim</name>
</author>
<entry>
<title>Atom 0.3 snapshot</title>
<link rel=”alternate” type=”text/html”
href=”http://diveintomark.org/2003/12/13/atom03″/>
<id>tag:diveintomark.org,2003:3.2397</id>
<issued>2003-12-13T08:29:29-04:00</issued>
<modified>2003-12-13T18:30:02Z</modified>
</entry>
</feed>
1.2 Conformance
[[ talk about atom documents and atom consumers, and how requirements are placed on them ]]
1.3 Notational Conventions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
This specification uses XML Namespaces [W3C.REC-xml-names-19990114] to uniquely identify XML elements and attribute names. It uses the following namespace prefixes for the indicated namespace URIs;
“atom”:
http://purl.org/atom/ns#
Note that the choice of any namespace prefix is arbitrary and not semantically significant.
Atom is specified using the XML Infoset [W3C.REC-xml-infoset-20011024], but uses a shorthand for common terms; the phrase “Information Item” is not used when naming XML constructs.
Therefore, when this specification uses the term “element,” it is refering to an Element Information Item in Infoset terms. Likewise, when it uses the term “attribute,” it is refering to an Attribute Information Item.
Furthermore, when it indicates that the content of an element or attribute is a “string,” it is referring to a set of one or more Character Information Items.
[[children / contains]]
TOC
2 Atom Documents
An Atom document is an XML document whose document element is the atom:feed element, as described below.
Atom is specified in terms of the XML Infoset, and therefore may be serialized in a variety of fashions. However, the canonical serialization of an Atom document is XML 1.0, and this is the only serialization that can be identified with the “application/atom+xml” media type.
Atom documents MAY have a Document Type Declaration.
[[Entities]]
Atom documents SHOULD NOT contain Processing Instructions, unless they are a commonly used convention outside the scope of Atom (e.g., the PI for XSLT processing).
Atom documents MAY contain Comments wherever they are legal in XML.
All elements and attributes in an Atom document MUST be namespace-qualified. Note that this requirement does not preclude the use of a default namespace.
Any element in an Atom document MAY have an xml:base attribute. However, XML Base [W3C.REC-xmlbase-20010627] processing MUST NOT be applied to element or attribute content, unless that element or attribute”s specification explicitly includes XML Base processing.
Any element MAY have an xml:lang attribute whose content indicates the default natural language of the element”s content. The content of this attribute element MUST be a registered language tag [RFC3066]. When determining element content”s natural language, the first xml:lang attribute encountered in that element”s ancestors MUST be used.
[[extensibility]]
TOC
3 Common Atom Constructs
Many of Atom”s elements share a few common structures. This section defines their requirements, for convenient reference by the appropriate element definitions.
When an element is identified as being a construct, it inherits the corresponding requirements from that construct”s definition in this section.
3.1 Content Constructs
A Content construct is an element with arbitrary child content, whose properties are described by the following attributes:
3.1.1 “type” Attribute
Content constructs MAY have a “type” attribute, whose value indicates the media type of the content. When present, this attribute”s value MUST be a registered media type [RFC2045]. If not present, its value MUST be considered to be “text/plain”.
3.1.2 “mode” Attribute
Content constructs MAY have a “mode” attribute, whose value indicates the method used to encode the content. When present, this attribute”s value MUST be listed below. If not present, its value MUST be considered to be “xml”.
“xml”:
A mode attribute with the value “xml” indicates that the element”s content is inline xml (for example, namespace-qualified XHTML).
“escaped”:
A mode attribute with the value “escaped” indicates that the element”s content is an escaped string. Processors MUST unescape the element”s content before considering it as content of the indicated media type.
“base64″:
A mode attribute with the value “base64″ indicates that the element”s content is base64-encoded [RFC2045]. Processors MUST decode the element”s content before considering it as content of the the indicated media type.
3.2 Person Constructs
A Person construct is an element with the following children:
3.2.1 “atom:name” Element
The “atom:name” element”s content conveys a human-readable name for the author. It MAY be the name of a corporation or other entity no individual authors can be named. Person constructs MUST contain exactly one “atom:name” element, whose content MUST be a string.
3.2.2 “atom:url” Element
The “atom:url” element”s content conveys a URI associated with the author. Person constructs MAY contain an atom:url element, but MUST NOT contain more than one. The content of atom:url in a Person construct MUST be a URI [RFC2396].
xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to the atom:url element.
3.2.3 “atom:email” Element
The “atom:email” element”s content conveys an e-mail address associated with the Person construct. Person constructs MAY contain an atom:email element, but MUST NOT contain more than one. Its content MUST be an e-mail address [RFC2822].
Ordering of the element children of Person constructs MUST NOT be considered significant.
3.3 Date Constructs
A Date construct is an element whose child content is a W3C Date-Time string [W3C.NOTE-datetime-19980827].
3.4 Link Constructs
A Link construct is an element that MUST NOT have any child content, and has the following attributes:
3.4.1 “rel” Attribute
The “rel” attribute indicates the type of relationship that the link represents. Link constructs MUST have a rel attribute, whose value MUST be a string, and MUST be one of the values enumerated in the Atom API specification <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</eref>.
3.4.2 “type” Attribute
The “type” attribute indicates an advisory media type; it MAY be used as a hint to determine the type of the representation which should be returned when the URI in the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation.
Link constructs MUST have a type attribute, whose value MUST be a registered media type [RFC2045].
3.4.3 “href” Attribute
The “href” attribute contains the link”s URI. Link constructs MUST have a href attribute, whose value MUST be a URI [RFC2396].
xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to the atom:url element.
3.4.4 “title” Attribute
The “title” attribute conveys human-readable information about the link. Link constructs MAY have a title attribute, whose value MUST be a string.
TOC
4 The “atom:feed” Element
The “atom:feed” element is the document (i.e., top-level) element of the format described by this specification. Its children are a (potentially partial) representation of the state of the feed.
The atom:feed element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. Ordering of the element children of atom:feed element MUST NOT be considered significant.
The following attributes and child elements are defined by this specification (note that it requires the presence of some of these elements):
4.1 “version” Attribute
atom:feed elements MUST have a “version” attribute whose content indicates the version of the Atom specification that the construct conforms to.
The version identifier for this specification is “0.3″.
4.2 “xml:lang” Attribute
atom:feed elements SHOULD have an “xml:lang” attribute whose content indicates the default natural language of the feed. The content of this attribute element MUST be a registered language tag [RFC3066].
4.3 “atom:title” Element
The “atom:title” element is a Content construct that conveys a human-readable title for the feed. atom:feed elements MUST contain exactly one atom:title element. If the feed describes a Web resource, its content SHOULD be the same as that resource”s title.
4.4 “atom:link” Element
The “atom:link” element is a Link construct that conveys a URI associated with the feed. The nature of the relationship as well as the link itself is determined by the element”s content.
atom:feed elements MUST contain at least one atom:link element with a rel attribute value of “alternate”.
atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of “alternate” that has the same type attribute value.
atom:feed elements MAY contain additional atom:link elements beyond those described above.
4.5 “atom:author” Element
The “atom:author” element is a Person construct that indicates the default author of the feed. atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element”s child atom:entry elements contain an atom:author element. atom:feed elements MUST NOT contain more than one atom:author element.
[[explain inheritence]]
4.6 “atom:contributor” Element
The “atom:contributor” element is a Person construct that indicates a person or other entity who contributes to the feed. atom:feed elements MAY contain one or more atom:contributor elements.
4.7 “atom:tagline” Element
The “atom:tagline” element is a Content construct that conveys a human-readable description or tagline for the feed. atom:feed elements MAY contain an atom:tagline element, but MUST NOT contain more than one.
4.8 “atom:id” Element
The “atom:id” element”s content conveys a permanent, globally unique identifier for the feed. It MUST NOT change over time, even if the feed is relocated. atom:feed elements MAY contain an atom:id element, but MUST NOT contain more than one. The content of this element, when present, MUST be a URI.
4.9 “atom:generator” Element
The “atom:generator” element”s content indentifies the software agent used to generate the feed, for debugging and other purposes. atom:feed elements MAY contain an atom:generator element, but MUST NOT contain more than one.
The content of this element, when present, MUST be a string that is a human-readable name for the generating agent.
The atom:generator element MAY have a “url” attribute whose value MUST be a URI. When dereferenced, that URI SHOULD produce a representation that is relevant to that agent.
The atom:generator element MAY have a “version” attribute that indicates the version of the generating agent. When present, its value MUST be a string.
4.10 “atom:copyright” Element
The “atom:copyright” element is Content construct that conveys a human-readable copyright statement for the feed. atom:feed elements MAY contain an atom:copyright element, but MUST NOT contain more than one.
The atom:copyright element SHOULD NOT be used to convey machine-readable licensing information.
4.11 “atom:info” Element
The “atom:info” element is a Content construct that conveys a human-readable explanation of the feed format itself. atom:feed elements MAY contain an atom:info element, but MUST NOT contain more than one.
The atom:info element SHOULD NOT considered meaningful by processors; it is a convenience to publishers in certain situations.
4.12 “atom:modified” Element
The “atom:modified” element is a Date construct that indicates the time when the state of the feed was last modified, including any changes to entries therein. atom:feed elements MUST contain exactly one atom:modified element.
The content of an atom:modified element SHOULD have a time zone whose value MUST be “UTC”.
4.13 “atom:entry” Element
The “atom:entry” element”s represents an individual entry that is contained by the feed. atom:feed elements MAY contain one or more atom:entry elements.
The atom:entry element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. Ordering of the element children of atom:entry element MUST NOT be considered significant.
The following child elements are defined by this specification (note that it requires the presence of some of these elements):
4.13.1 “atom:title” Element
The “atom:title” element is a Content construct that conveys a human-readable title for the entry. atom:entry elements MUST have exactly one “atom:title” element. If an entry describes a Web resource, its content SHOULD be the same as that resource”s title.
4.13.2 “atom:link” Element
The “atom:link” element is a Link construct that conveys a URI associated with the entry. The nature of the relationship as well as the link itself is determined by the element”s content.
atom:entry elements MUST contain at least one atom:link element with a rel attribute value of “alternate”.
atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of “alternate” that has the same type attribute value.
atom:entry elements MAY contain additional atom:link elements beyond those described above.
4.13.3 “atom:author” Element
The “atom:author” element is a Person construct that indicates the default author of the entry. atom:entry elements MUST contain exactly one atom:author element, UNLESS the atom:feed element containing them contains an atom:author element itself. atom:entry elements MUST NOT contain more than one atom:author element.
[[explain inheritence]]
4.13.4 “atom:contributor” Element
The “atom:contributor” element is a Person construct that indicates a person or other entity who contributes to the entry. atom:entry elements MAY contain one or more atom:contributor elements.
4.13.5 “atom:id” Element
The “atom:id” element”s content conveys a permanent, globally unique identifier for the entry. It MUST NOT change over time, even if other representations of the entry (such as a web representation pointed to by the entry”s atom:link element) are relocated. If the same entry is syndicated in two atom:feeds published by the same entity, the entry”s atom:id MUST be the same in both feeds.
4.13.6 “atom:modified” Element
The “atom:modified” element is a Date construct that indicates the time that the entry was last modified. atom:entry elements MUST contain an atom:modified element, but MUST NOT contain more than one.
The content of an atom:modified element MUST have a time zone whose value SHOULD be “UTC”.
4.13.7 “atom:issued” Element
The “atom:issued” element is a Date construct that indicates the time that the entry was issued. atom:entry elements MUST contain an atom:issued element, but MUST NOT contain more than one.
The content of an atom:issued element MAY omit a time zone.
4.13.8 “atom:created” Element
The “atom:created” element is a Date construct that indicates the time that the entry was created. atom:entry elements MAY contain an atom:created element, but MUST NOT contain more than one.
The content of an atom:created element MUST have a time zone whose value SHOULD be “UTC”.
If atom:created is not present, its content MUST considered to be the same as that of atom:modified.
4.13.9 “atom:summary” Element
The “atom:summary” element is a Content construct that conveys a short summary, abstract or excerpt of the entry. atom:entry elements MAY contain an atom:created element, but MUST NOT contain more than one.
4.13.10 “atom:content” Element
The “atom:content” element is a Content construct that conveys the content of the entry. atom:entry elements MAY contain one or more atom:content elements.
If @type=”multipart/alternative”, @mode MUST NOT be specified, and content element MUST contain 1 or more content elements. These content elements MUST NOT specify @type=”multipart/alternative” (i.e. only one level of nesting is allowed). Consumers SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). Consumers SHOULD NOT render more than one content alternative.
TOC
5 Managing Feed State
[[ talk about what it means to keep a view of a feed ]]
TOC
6 Embedding Atom in Other Formats
[[ ... ]]
TOC
7 Extending Atom
[[ ... ]]
TOC
8 IANA Considerations
The Atom format, when serialized as XML 1.0, can be identified with the following media type:
MIME media type name:
application
MIME subtype name:
atom+xml
Mandatory parameters:
None.
Optional parameters:
“charset”:
This parameter has identical semantics to the charset parameter of the “application/xml” media type as specified in RFC 3023 [RFC3023]. [RFC3023].
Encoding considerations:
Identical to those of “application/xml” as described in RFC 3023 [RFC3023], section 3.2.
Security considerations:
As defined in this specification. [[update upon publication]]
In addition, as this media type uses the “+xml” convention, it shares the same security considerations as described in RFC 3023 [RFC3023], section 10.
Interoperability considerations:
There are no known interoperability issues.
Published specification:
This specification. [[update upon publication]]
Applications which use this media type:
No known applications currently use this media type.
Additional information:
Magic number(s):
As specified for “application/xml” in RFC 3023 [RFC3023], section 3.2.
File extension:
.atom
Fragment identifiers:
As specified for “application/xml” in RFC 3023 [RFC3023], section 5.
Base URI:
As specified in RFC 3023 [RFC3023], section 6.
Macintosh File Type code:
TEXT
Person and email address to contact for further information:
Mark Nottingham <mnot @pobox.com>
Intended usage:
COMMON
Author/Change controller:
This specification”s author(s). [[update upon publication]]
TOC
9 Security Considerations
[[ this is required ]]
TOC
References
[RFC2045] Freed, N. and Borenstein, N.S., “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R.T. and Masinter, L., “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.
[RFC2822] Resnick, P., “Internet Message Format”, RFC 2822, April 2001.
[RFC3023] Murata, M., St. Laurent, S. and Kohn, D., “XML Media Types”, RFC 3023, January 2001.
[RFC3066] Alvestrand, H., “Tags for the Identification of Languages”, BCP 47, RFC 3066, January 2001.
[W3C.NOTE-datetime-19980827] Wolf, M and Wicksteed, C, “Date and Time Formats”, W3C NOTE NOTE-datetime-19980827, August 1998.
[W3C.REC-xml-infoset-20011024] Cowan, J and Tobin, R, “XML Information Set”, W3C REC REC-xml-infoset-20011024, October 2001.
[W3C.REC-xml-names-19990114] Bray, T, Hollander, D and Layman, A, “Namespaces in XML”, W3C REC REC-xml-names-19990114, January 1999.
[W3C.REC-xmlbase-20010627] Marsh, J, “XML Base”, W3C REC REC-xmlbase-20010627, June 2001.
TOC
Author”s Address
Mark Nottingham
EMail: mnot@pobox.com
URI: http://www.mnot.net/
TOC
A Contributors
The following people contributed to this specification”s content: Tim Bray, Mark Pilgrim, and Sam Ruby. The content and concepts within are a product of the Atom community.
TOC
B Revision History
2003-12-12 (-02):
Fixed several typos, clarified some langauge.
Reference to RFC3066 for language tags.
Explained purpose, clarified requirements of atom:info.
Relaxed requirements for atom:issued date.
Added reference to API spec.
Added example.
Expanded upon Atom”s use of XML (now “Atom Documents”).
Expanded upon notational conventions.
Added xml:base requirements to atom:author, atom:link.
Adjusted time zone requirements for dates.
rel attribute values are constrained to those listed in the Atom API.
2003-12-11 (-01):
New format for atom:generator.
New format for atom:link.
Added atom:info
Many elements are now Content constructs.
Made it explicit that ordering in containers isn”t significant.
Added references.
Added media type registration template.
Reorganization.
Feb 11
IUSR咿咿呀呀
又是凌晨2点了，最近过年爸妈也不管我熬夜了，真的让我过足了瘾。
别人都在睡觉，只有我是醒着的。呵呵，听起来好像很厉害一样:P
最近都在忙着跟计算机发展感情，每天早晨，呃，中午起来就打开它，一直到睡觉时。先是忙着实践ant和junit，后来开始参与jnn，参与着发现自己不太可能适应它的代码时就开始另起炉灶，做自己的rss客户端，但这何其难也，尤其对我这种GUI白痴来说，做一晚上的Swing在以前是无法想像的……
就要开学了，呵呵，妈妈的，这才放了一个月而已，有些同学3月初才开学了，不知道英明的校领导是不是怕我们在家呆的时间太久会说一些败坏他们名声的话，所以急着把我们拉回去……
恩，马上就要开学了，我是该期待能让我满足的网速，还是对这但愿是最后一个学期的生活感到恐惧？
我爱我自己
RSS
Recent Comments