Slashdot Mirror

OpenSearch RSS 1.0 is an extension to the RSS 2.0 standard, conforming to the guidelines for RSS extensibility as outlined by the RSS 2.0 specification. The intent is to provide a standard format for returning results for a search query. This extension is designed to be backward compatible with existing RSS readers.

Version 1.0 of OpenSearch RSS adds only three new elements, each within the openSearch XML namespace. Additionally, OpenSearch 1.0 makes recommendations on how existing RSS 2.0 elements can be best used within a search context.

Future versions of OpenSearch RSS will attempt to maintain backwards compatibility with OpenSearch RSS 1.0. More complicated search extensions to RSS 2.0, such as language selection, encoding type, spelling suggestions, multi-media results, sponsored links, etc, will be done in such a way as to keep OpenSearch RSS easy to implement and interpret.

See Very Dynamic Web Interfaces by Drew McLellan based on this earlier blog entry by him.

I don't think you need a database necessarily, and you don't need 1337 XML skillz either. Check this out for a simple tutorial on XMLHttpRequests.

• General Javascript documentation: http://www.devguru.com/Technologies/ecmascript/qui ckref/javascript_intro.html
  
• Writing to <div> tags from Javascript: http://www.howtocreate.co.uk/tutorials/index.php?t ut=0&part=14#dhtmlCONT
  
• Accessing XML Nodes from Javascript: http://www.mozilla.org/xmlextras/xmldataislands/
  Every other tutorial I found says to use something like node.firstChild.text for getting the value of an element, but I couldn't get that working on Firefox or Safari. This just mentions to use node.firstChild.nodeValue which did the trick for me.
  

...scripting is a terrible way to handle form input. It just doesn't scale...

This is just plain wrong. The current use of forms over HTTP scales beautifully because it separates the user-agent (browser) from the application. No tightly-bound system in existence can handle the load that web applications handle [and you doubters best remember that the green-screen mainframes use request-response protocols almost exactly like HTTP].

See Roy Fielding's work on REST to understand why web applications DO scale so well. And here's a simple example of REST.

I happen to have recently surveyed XForms engines, and at least two of them under development run entirely within the client, in the style of gmail, Google Maps, Flickr, etc.

Modern browsers are up to this, it just takes a (one-time) engineering effort, treating JavaScript as a full programming language.

Of course, if browsers like Mozilla natively support XForms, all the better. -m

an article titled Printing XML: Why CSS Is Better than XSL written by Michael Day and Håkon Wium Lie. The article was written in response to Norm Walsh's claim that CSS will never fix [printing]. Did you hear me? CSS will never fix it!".

Let the hair pulling and the name calling begin.

You are right that XML (and kin) are not typesetting systems.

However, there is a language called XSL:FO (Formatting Objects) written on top of XSL that can be used to describe typsetting for XML documents, as printing is just one sort of transform. People usually use it to produce PDF's of data, but I have seen it used to produce a book of medical images.

Personally, I've ejoyed the following lately:

• PSK-31 -- a cheap soundcard-based text-to-text mode that uses only 31Hz of bandwidth and goes around the world on 5 watts
• XML for Ham Radio -- I've started a consortium to develop XML standards for ham radio, starting with an extensible logging format, and working with everyone from QRZ and eQSL.cc on the server side to xlog for Linux and Ham Radio Deluxe for Windows and others.
• RPSK -- a TCP/IP based protocol for remote operation of a PSK station with a Java applet client and a hiptop client. (The antenna is not hooked up right now so don't expect the applet to work.)
• HFPack -- portable and picnic table operation with HF radio; I talked to Estonia with an Elecraft KX1 and about 4.5 Watts
• An RSS feed for APRS -- working with APRSWorld I developed an APRS to RSS converter to help HFPackers let people know where and when they are operating, so people can listen for them.
• Kit building -- I have built an Elecraft K2, one of the most sensitive ham transceivers in the world, their KX1 (one of the smallest and most featureful), a Small Wonder Labs PSK-20 specific to PSK on 14.070 MHz, and a variety of American QRP Club and Four-State QRP Club kits. For more power, I built an 50 Watt HF Amplifier in a group project and am working on a 100W one.
• CW -- I learned Morse Code at 5 so it was easy to pick back up after a couple (ok, a few) decades of disuse, and it's been a blast as well.

Check it out and take a look at my Ham Web Log for more stuff.

Put this at the very top of every HTML page:

<?php
/* XHTML proper header for browsers that accept it. If using Mozilla, this is one way to make sure your XHTML validates */
if(isset($_SERVER['HTTP_ACCEPT']) AND stristr($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml'))
{
header('Content-type: application/xhtml+xml');
}
else
{
header('Content-type: text/html');
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
< html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

Then if you do your development in Mozilla/Firefox, it will die any time your XHTML is malformed.

It has the added benefit of something you would leave in on your production server.

It doesn't matter if Internet Explorer supports this. The great thing about XForms is that it can be implemented on the server-side. Take a look at chiba, which is real technology you can use today (and I am using), to develop with XForms. Servlets not good enough? Take a look at 10 different XForms implementations Who cares what IE does?

This is helpful.

Not really yet ready though.

Generating Word documents using XSLT

Thinking XML

Opening Open Formats with XSLT

Office 2003 XML Reference Schemas Overview

Why You Should Choose MS Office Over OO.org

Why not complicate a complicated world a little more. Each standard unit of complication renders X standard monetary units in someones pockets.

CC.

As I remember all the negative articles were based on early access MSDN stuff (there were dozens of them at the time), so I'm open to the idea that they were all wrong. Since I don't have Office 2003 yet and I'm still running Office XP, I don't have the interest or means to verify any of this personally. If somebody would care to show me somebody's actual review of the relevant schemas and document that in fact they are complete, human and machine parseable, and do not contain big chunks of essentially unmungeable data, then that's great. Just telling me that you glanced through the schemas yourself doesn't really provide me with much information - did you write an application that parses and displays complete Microsoft Word docs with embedded Excel spreadsheet charts?

Try Google, newbie :-)

I tried to submit similar article on Jan 22 but it was not accepted. Evidently Microsoft responded to the complain and Apache is not blacklisted anymore. Below is my original one month old post. Sorry URL show proper results now and I did not saved the original search results.

A few days ago I noticed that every time I use Internet Explorer (i.e. MSN search) to look for apache related projects I never got a reference to apache.org websites.

Examples: jelly script , maven apache , cocoon framework .

*.apache.org sites never came up. I am not even talking about listing it as "featured web site". It never came up as the link at all!!! The best you would get is a reference to XML.com website discussing the technology but not to technology itself.

Even search for "apache web" got the reference www.apache.com as the featured site instead of www.apache.org Only "apache" got "apache.org" as the featured site at the second place after oil related Apache corporation. Yahoo and Google as you would expect did proper job.

I wrote an article about how

Web Services broke a few months back -if sitefinder returns it will need rereading.

I couldn't agree more. A month ago I started serious kernel programming and my code wouldn't have been what it is if I hadn't found out about the free, online version of the second edition.

Some other useful sites :
the Linux kernel API reference

Linux cross reference, especially the `identifier search'.

the driver porting series over at LWN.net (which Rufus211 alreay pointed out).

the module init tools FAQ

this document, aptly titled `the linux kernel'

apart from these there are many more interesting links, but mostly those have to do with specialty domains, such as networking or memory management. I pasted my bookmarks.html to my personal website.

And lastly, if you want to do cross-version /dev (mknod and devfs), mmap, module or networking development, please take a look at our project's cvs server through our website (webcvs) at ffpf.sourceforge.net. The directory ffpf/srv/v1.1/generic contains some files I created that work on both 2.4.24 and 2.6.1 and which I'll test on a 2.3.99 system shortly.

I wrote an article on this not so long ago, The impact of sitefinder on Web Services.

All verisign are trying to do is steal the revenue that MS get with their 90+ share of the browser world. But MS wont like, and will come up with a workaround, like a 'critical' IE patch.

but in the meantime, everyone whose app uses DNS suffers, not just web browsers. Web Services -programs hitting servers for their own posts and gets- really suffer, because any configuration failure now results in really obscure messages (bad mime type), (307: not supported), instead of ones that users are vaguely familiar with ('not found), and that makes diagnostics and support worse. Once people start patching their DNS, a lot worse, as replication gets harder.

That is what irritates me: Verisign are screwing up every network application other than a web browser to get advertising $.

And what was wrong with Lilypond's format? I know it's not that pretty but it works and is unencumbered. Was it because it wasn't buzzword compliant?

If anybody rates as TIoX, it has to be Jon Bosak, who was the first to understand the shortcomings of SGML, and managed to persuade the world at large that the XML effort was necessary. But then, Jon was also smart enough to see that he couldn't do it all himself, and drafted a bunch of people, including Bray, to help him. So he'd probably reject the title too.

If anybody rates as TIoX, it has to be Jon Bosak, who was the first to understand the shortcomings of SGML, and managed to persuade the world at large that the XML effort was necessary. But then, Jon was also smart enough to see that he couldn't do it all himself, and drafted a bunch of people, including Bray, to help him. So he'd probably reject the title too.

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

The problem is not the protocol, the problem is XML's insistence on "one XML document per stream" being a rock-hard rule. I consider a mistake but Tim Bray says it's an advantage in just this situation.

If you could have more then one root element then your DOM library would already support multiple documents coming in as discrete chunks.

There's really no way in an XML protocol around this; dispense with the element at the beginning and you can no longer think of the Jabber communication as a single XML document. Now you've got other problems.

Of course you can now say "Well Jabber shouldn't be XML then" (though I don't know that you personally would), but of course Jabber is XML for other reasons, reasons I consider very good ones. (Few people have truly taken advantage of these reasons but I'm working on it; part of the problem is that I'm first having to build an innovative way to parse XML because neither DOM nor SAX paradigms work; but again, that's a weakness of the XML libraries, not Jabber!)

XHTHML

... which should be XHTML of course :-) Pity that it is served as text/html instead of application/xhtml+xml, like it should be.

Here is a link to a interesting article by Paul Prescod which explains the significance of SVG in the vector graphics market. Despite Flash's success and Microsoft's monopoly advantage as they enter the market, there will still be a single open format by which vector graphics may be transmitted between applications. At this time, Adobe products, OpenOffice, to name some big supporters, allow conversion to SVG. It makes sense to have a open-standardized transmission language for vector graphic formats, even if nobody actually implements a viewer/creater for the format!

DTD Repositories

There are some other great ones out there, but that should get you started.

That reminds me vaguely of the (now-defunct) XMLTerm project.

Good points to think about.

I'd settle for eliminating plug-ins entirely, but solidifying support for W3C standards such as SVG and X3D.

With some work in ECMAscript (Javascript), dynamic illustrations in SVG could be turned into the various widgets that people expect from a modern GUI, but they'd be built-in to a browser and be cross-platform.

Then IE, Mozilla, Opera and anyone else would be free to implement renderers and interactors without fearing whether they're infringing on someone's patent.

Widespread adoption of these standards for interactive and scalable graphics would be a tremendous benefit in getting rid of all the various paper-centric publishing solutions that plague us today.

RESTful web services are the services primarily in place today: they utilize existing WWW security standards, are easy to implement and debug, and are available today.

• REST Wiki
  
• Building Web Services the REST Way
  
• Paul's REST Resources
  
• REST and the Real World
  
• Second-Generation Web Services
  

RESTful web services are the services primarily in place today: they utilize existing WWW security standards, are easy to implement and debug, and are available today.

• REST Wiki
  
• Building Web Services the REST Way
  
• Paul's REST Resources
  
• REST and the Real World
  
• Second-Generation Web Services
  

I like the idea though, and I'm a bit saddened by the fact that no-one's doing much to advance the state of the CLI. I think there's plenty to be done, and not just with CLI/GUI fusion.

And you can read the whole thing for free here.

SVG is very promising, but Flash already is available for 95% of the computers.

SVG is much more than a competitor to Flash or other proprietary formats.

SVG is similar in scope to Flash, but it is a W3 recommendation (i.e. a standard) and uses an open format.

SVG is actually much broader in scope than Flash, PDF, or other proprietary formats, as aptly pointed out by Paul Presod at SVG Open 2003.

Furthermore, the XML project of the Apache Software Founcation is hard at work on Batik, a Java-based toolkit for applications or applets that want to use images in the SVG format.

I agree completely that browsers need to support SVG, and until this is more advanced, tools like the one in this article are getting ahead of things

According to this logic, Adobe is getting ahead of themselves making products that generate PDF until the browsers natively support PDF. PDF is handled by a plugin. SVG is handled by a plugin. They plugins come from the same company. So why is native browser support a necessary condition for SVG's success?

That said, there are some advanced features that can be only accomplished if SVG is native in the browser but that is necessary for it to become more important to the Web than PDF or Flash. But merely to be in the same league a plugin is fine.

Ultimately, this needs to be done without plugins -- its really just another image format.

Uhhh...no it isn't. SVG is designed to be much, much more than just another image format. For instance it can be the basis for fonts. It has full multimedia sequencing. It can be used as a page description language in printers. But most important: it is designed to be integrated with XHTML so that you authors can seamlessly move back and forth between XHTML, SVG, SMIL, XLink, XForms etc. It is a key part of the next generation of browser and not just another file format (once we get beyond the plugin stage). More here.

As to your second paragraph, I don't seem to get what you are talking about. Stream-based APIs and XPath generally don't mix at all - how should an XPath expression like //foo[position()=last()] be handled in, say, a SAX handler?

There is, however, some kind of middle ground, namely Streaming Transformations for XML, an XSLT-ripoff based on SAX with a limited XPath lookalike. Quite useful, IMHO.

The article is actually on xml.com, not xml.net. Here is the url: http://www.xml.com/pub/a/2003/07/09/xmlapis.html

Bingo.

Don't think that O'Reilly doesn't know this either. Check out how many books, articles, and so forth they have published since OS X came out. I had the privilege a few months ago to have a sit down with the current editor of the Apple books, and from the way he talked it seems that O'Reilly is nothing short of ecstatic about the OS.

O'Reilly, IMHO, publishes by far the best books on the market. This is because they have excellent editors and scouts (for lack of a better word) to find very intelligent, very insightful people to write their books. I suggest people check out there dev sites more often; they are treasure troves of info

The O'Reilly Network

MacDevCenter.com

OnDotNet.com

OnJava.com

OnLamp.com

openp2p.com

osdir.com

Perl.com

XML.com

This article has a great discussion on transitioning to XHTML and suggests a very cool trick for how to handle browsers that don't like application/xhtml+xml:

http://www.xml.com/pub/a/2003/03/19/dive-into-xml. html

-h3

Well, technically it isn't breaking the spec, just bending it really far. The spec actually reads that html 4.01 _should_ be served as text/html, xhtml 1.0 _should_ be served as application/xhtml+xml, xhtml 1.1 _should_not_ be served as text/html, and it is very likely that the xhtml 2.0 spec will say that xhtml _must_not_ be served as text/html. So, while the spec strongly recommends against serving xhtml as text/html, if it keeps IE rendering the page, then I'm happy.

This was all taken from Mark Pilgrim's "Dive into XML" article available here.

Comedi is awsome. The very first driver described leads to The 8255 driver. It's author, Daniel Franklin, recomends "Alessandro Rubini's excellent book Linux Device Drivers (another fine O'Reilly publication)" Ahh, knowledge, what could be finer. Free software, free info. Go get it and become the research tech God you want to be.

As a couple people have already pointed out, if you're serving XHTML with the proper MIME-type of "application/xhtml+xml", Mozilla will show you XML parsing and well-formedness errors instead of trying to render the page; there's a good article on the XHTML MIME-type along with instructions on how to serve that MIME-type only to browsers which understand it over at XML.com.

As a couple people have already pointed out, if you're serving XHTML with the proper MIME-type of "application/xhtml+xml", Mozilla will show you XML parsing and well-formedness errors instead of trying to render the page; there's a good article on the XHTML MIME-type along with instructions on how to serve that MIME-type only to browsers which understand it over at XML.com.

The main thesis of Tim Bray's original post was that he didn't like having to choose between either storing all his data in memory (i.e. DOM) or using a callbacks(i.e. SAX) when processing XML. The problem with this kind of thinking is that although it may have been true two or three years ago that the only way to process XML was via DOM or SAX this is no longer the case.

There are more classes of APIs supported on multiple platforms for processing XML such as pull-based APIs and cursor based APIs which are represented by the System.Xml.XmlReader and System.Xml.XPath.XPathNavigator in the .NET Framework. Similar APIs exist in the Java world as well as Python from what I've heard. This is besides the current push in some quarters for programming languages that natively process XML (i.e. intrinsicly understand an XML datamodel or datatype).

Tim Bray's original problem was that he doesn't have a pull-based API for XML parsing in Perl. I pointed out in my kuro5hin diary how the pseudo code he showed as being his ideal for processing XML already exists in C# and .NET Framework. This article on XML.com points to other people who also point out that such pull-based APIs for processing XML are available on other platforms and languages as well.

• High-Performance XML Parsing With SAX
• Transforming XML With SAX Filters
• • There are others too. Easy to use and does pretty much what he wants.

• High-Performance XML Parsing With SAX
• Transforming XML With SAX Filters
• • There are others too. Easy to use and does pretty much what he wants.

Well said, but it also brings up the point of people whose reflexive need to jump up and down waving their arms in the air screaming "Micro$oft Bad!!!" is downright Pavlovian.

It's pretty clear midway through paragraph 3 that it's OpenOffice FUD.

here's a link for anyone who would actually like to read about XML rather than parrot about it being just another file format.

Just because you say it with smug conviction doesn't make it true.

The new XHTML 2.0 introduces XForms integration, navigation lists, linking on every element, unordered section headings, and an expanded role for the object element.

A XML Schema is a way to define a set of XML data as set forth in the applicable W3C standards. A Scheme is a scam perpetrated by scam artists, e.g. the television industry. I stand by my English as used in my original post.