RSS technology standards of many shortcomings is also its advantages

rss| Standard

There is a wide variety of syndication (WEB syndication) technologies on the Global Information network. As the proverb goes: The best part of the standard is that there are too many standards.

If you really want to put RSS 1.0, RSS 2.0 (in fact, not the RSS 1.0 version, but 0.94), atom and a wide range of other Internet syndication technology to make a clue, I am afraid to do a master's thesis-level research. If there is a problem at the normative level and there is no solution (some of the conflicts are exaggerated by the press in my opinion), how can we expect that the front-line applications will become easier to use? This article will discuss scenarios where users try to make use of existing technologies.

One of the RSS 2.0 problems I came across is that web publishers often use different conventions to publish information sent by RSS (Really Simple Syndication syndication) system. While this elasticity is one of the best benefits of RSS 2.0, it's a move to the listener side, such as standardizing multiple RSS feeds to make the burden of the presentation. Although end user applications (including RSS readers) usually contain artificial intelligence, can remedy problems with inconsistent file formats (which also means that the app for RSS is pretty good), but I doubt that RSS will prove to be extremely difficult for software vendors to deliver on their promises--they promise to provide for the average person Software developed to enable technical novices to use only cursors and mouse clicks and drag, but also to create a complex, transactional (transactional), server-side applications.

After all, RSS is one of the best examples of what Extensible Markup Language (XML) can do for the general public today, as well as the closest contact that most people have to XML. The popularity of RSS feeds is likely to evolve into the primary way in which all information, whether structured or loose, is collected-whether it is used only to browse the latest blog (Weblog) to update content, to retrieve e-mail (hey, isn't that the end of spam?). or through a complex workflow to deliver transaction information. In this context, RSS may also be used as a litmus test for "point-selection program design " (Point-and-click programming).

To encourage online collaboration through the ZDNet blog, we have built an in-house wiki. It may be richer in the future, but at the moment our Wiki homepage is more like a shared bookmark showroom. I've built a secondary web page that shows the power of multiple user systems: The blog Glance that my work group must track. I use the TWiki title plug-in program to RSS-based joint content to the same Web page, basically the Web page equivalent to a corner of the blog to set up a portal site , so that we observe the blog I think should not be missed. I call it our radar.

I added content from the blogs of Robert Scoble, Jonathan Schwartz, Tim Bray, Bob Frankston, Slashdot, Groklaw, and soon after, Zdnet.com vice President Stephen Howard-sarin also added some of the Web pages from Dan Bricklin, Jon U Dale, Dan Gillmor, Phil Windley, Doc Searls and others. Although this is not called "point-to-point server-side programming," I think it's very close.

But I'm not happy with this. The default content capture format for the add-in, and how it renders on a Web page. So, to 牵就 our needs, I added some selection parameters (optional parameters) outside the plugin to determine that the last page displayed was plain text (for performance sake) and that only the latest five titles were retrieved from a variety of content sources. Presenting this type of selection parameter graphically, generating the encoding automatically, and embedding the source code in the Web page is exactly what I expect the "point-selection program" To do for me, rather than doing everything in hard-coding (my current practice).

As wikis generally become politically correct, Howard-sarin also follows the format I used when adding blog content. Because of the lack of easy-to-use tools, he only copied the source code in the form of clips and provided an indispensable substitute. Is it good enough for a group of non professional programmers to do that? In just a few hours, the two of us worked together to create a portal site that provided meaningful information and would rearrange updates with each page. Now, just wait for other ZDNet users to throw their favorite, repetitive web content into the Web page.

However, there is a problem. Some of the content can not be displayed properly, so I spent more time than the original plan. For example, each of the contents of Jonathan Schwartz's blog is presented in a way that is different from others--in his XML-formatted content, each repetitive blog content (called an item) omits the link bar (the link field). Most of the content, such as the one retrieved from ZDNet, uses a link bar to store the generic resource identifier (URI) to connect directly to the individual item (in this case, a news report, not a log in the blog). Omit the link bar, Schwartz dependent GUID (Global uniqueness identifier, pronunciation "Gwid") column with the option (called "Permalink") to store the resident link to connect to the individual blog posts. This makes sense, because connecting to a particular content across the Internet is one of the most unique ways you can find and use proprietary links. Maybe you can think of another way, but why should you spend it? Based on this rationale, almost everyone has a direct link to each of their content in the GUID. For many people, this means that the information found in the GUID is exactly the same as the information in the link bar (if they are used).

Is that important? Well, as far as I'm concerned, I think it's important, because I'm trying to figure out a plug-in parameter combination that can be easily reused ("point-and-choose programming" terminology will be called "objects", but I'll wait until I see it for myself) to build our portal page, The combination should be able to treat the various content sources observed on this page in the same way. If an object is only occasionally useful in the real world of "point-selection programming for ordinary people", then it is not long before the average person abandons the mouse.

Referring to the TWiki file as an example of a link bar, I began to try to use it to provide a link for portal users to return to the original source of content. That's reasonable, isn't it? However, once the link bar is omitted, as in the case of Schwartz blog, even if I have one by one attached links on the portal page, it is just a dead link. To study this issue, I further explore the weakness of RSS-I do not think that other users who only use the power of the Web syndication will have to delve into it. I found that if Schwartz's blog was to deposit each content-specific URI in the GUID (as he did), then I could rely on the GUID directory to bring the user back to the original source of the content. On the ability to reuse, I consider applying this approach to all the content we watch.

The following section is a canonical example of RSS 2.0, which shows that links are not necessarily the same as GUIDs, and that the solution I am inclined to adopt is right:

" a common question about S is how to differentiate it from S, isn't that the same thing?" Yes, it's true in content systems, but not in other systems. In some systems, S is the permalink of online records. But in other systems, each < item> is the full text of the summary, s points to the text, and S is connected to the content of the blog Permali NK. In any case, you are advised to provide the GUID and to render it as permalink as possible. Doing so prevents the collector from repeatedly retrieving the same item, although the item may be different because it has been modified. "

These are the best examples of expert advice, and there is no doubt that the trend is looming and that many content supply systems follow different conventions. This is the problem I have encountered. Now, the repeatability has been voted out, and I haven't even started to use the mouse to "point-and-choose programming". For every content source I add to the portal page, now I'll look at its XML and decide which set of parameters to use.

But the problem with the GUID relative to link is not the only challenge we face.

Some content supplies feeds, like Dave Winer's scripting News, and throws out a change ball. Winer's blog article does not attach title. This is a problem, because to build a portal with more than 20 sources and a clear view, we decided that the simplest way is to display only the title of the item, and then attach the link to the full text (using the item link or GUID mentioned above, depending on which comparison is applicable). However, in the case of Winer XML, there is limited ability to retrieve things. There is no title to choose from, you can only retrieve the other three kinds of--guid, item release date (pubdate), or item (narration) of the full text. But the full length of the item ranges from a few to a few, and it doesn't make sense to use it as a hypertext link (hyperlink).

Like Schwartz's blog, the Winer GUID is a URI that is connected to the Full-text. In other words, the text that we use to link to is only the release date. Obviously mozilla.org's feelings about untitled item are the same as ours. The Firefox browser uses a feature called Live bookmarks to track RSS feeds, which, in the case of untitled item, provides the release date as a clue to the original text in order to produce a selectable content link menu. In fact, in the processing of different specifications of RSS applications, Firefox performance of a good, even in the same blog with some item title, and some do not have the title of the John Robb Channel, can also maneuver strain. The Robb Blog to join the Firefox live bookmark, the resulting menu that shows Firefox from each item in situ selection, some retrieve the release date, some retrieve the title. This confirms the previous article, on the network syndication, the choice of the supply side, the consequences of its ramifications are borne by the listener this end. In other words, the transfer of control from the supplier side to the content publisher. It is noteworthy that this phenomenon seems to run counter to the trend of the global information network. (Internet Explorer is a large number of users, and many Web sites with Firefox can not be normal display, later see the Ming, you can verify that the supply side will always adapt to the demand side to make adjustments.) ）

Similarly, once again, the usual software will make complex decisions and algorithms for the user, and Dave Winer's website content collector has also made a commendable contribution by standardizing a wide variety of content practices to form a single interface through which the articles from different channels are mixed together, Sorted in reverse order by the time the sink is retrieved. For example, at 12:15, a channel may show five, but one of the earliest publications may not be more new than the ones in front of it, from another channel. However, regardless of which one, the release time is displayed according to the timezone of the terminal user's location. It is not possible to automatically find the terminal user's time zone, I am not sure, but in the case of Firefox and newsgator such as RSS feeds in the United States. See the space for growth in the future?

At first, I secretly cursed Winer unexpectedly not to attach title. But once I started tracking Winer's blog, I realized that the choice was justified. His blog is just a stream of consciousness log. When people think, will the title first? No way. Winer not, and no such need. He and other people's blog is very readable, and the title of the news report is different, because the blog is like a diary general. These blog has many chapters is to think of what on the 援笔, if the author must stop to first for each title, may not keep up with Mercedes-Benz thoughts. These are special cases. Another popular blog, the author is Microsoft 's Robert Scoble, no matter how short each space, are all titles. As an example of a recent talk about the Apple ipod by Steve Ballmer, Microsoft's chief executive, the headline is almost as long as the full text. If he gives the blog post less headlines, or a headline, maybe we can get a deeper understanding of Scoble's mind.

To build a reusable set of parameters (so that other people just need to cut the clip paste), I had to stare at Winer's content, and the more I stared at it, the more I found myself struggling with the trade-off between the two choices: using the release date as the link text for our TWiki architecture portal, or simply download and display his full text (stored in the description bar of each item) on our portal page? After all, our content only shows up to the latest five, and Winer regularly publishes more than five a day, so if you are listing a list of release dates, it will be nothing more than telling you when it is published. The message we really need is what is in the full text. Encounter Winer This does not attach title content, our only choice is to retrieve the full text (depending on the capacity of the plug-in program allowed).

In fact, the complete capture of a single breath (including GUIDs, narrations, release dates and the rest of the material provided by a source) is gradually the most common approach for our portals. It's done. Can I finally go back to my daily job? Oh, not yet.

As Winer suits me, that might not work, because unlike many blogs, news sites usually provide summaries in the narrative of each story, rather than the full text. To make it worse, even with the narrative, I found that TWiki's title plugin was not able to handle Hypertext Markup Language (HTML) format, and network news was written almost exclusively in this format.

The experimental plan is like a leaky dam in the old cartoons. Just when you think all the loopholes are plugged, another leak comes out. In the end I had to make a wish, but for the wise man to invent a way to solve the problem, as the software development company has always promised. But, judging by the pace of progress now, I suspect it may be a few more years.

But this article is still a story about the benefits of RSS--and it's also an illustration of why RSS-specific resilience makes life difficult for people trying to order in chaos, say software developers. After all, chaos is the norm of the Internet.