Slashdot Mirror

By digging one more layer down, you can find this at W3:

Abstract

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.

By digging one more layer down, you can find this at W3:

Abstract

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.

A protocol which allows remote object interaction (c.f. DCOM, RMI) by using standard format XML messages passed over HTTP. SOAP is essentially an open standard but it is being heavily promoted by M$ within their .NET framework, Sun have blown hot and cold over it for the last 6 months or so. Currently they say it's a good thing.

Check here for more info.

We could quibble about whether the first web browser was really an innovation or not. Berners-Lee has been quite modest, as well as very honest about his debts to SGML, HyperCard, and Xanadu.

Still, prior art notwithstanding, it does seem reasonable to accept web browsers as an FS/OS innovation, by which I mean a new user-facing product category. In fact it was the biggest new product category of the nineties. So this should be taken as a partial answer to concerns about FS/OS stifling innovation.

Tim

It looks like the source to WorldWideWeb.app (the original NeXTstep Web Browser) is here. I haven't seen any sort of license in the source files that are still there though...

We're bought and sold for corporate gold

About discovering method names - that's a classical problem in all distributed systems. I know that SOAP guys have tried to solve it by using UDDI (Universal Description, Discovery and Integration standard) - IBM just released open source for UDDI. If you like, you can download it from IBM's open source sub-site.

Look at XML Schema for how to use datatypes in XML. I think I get your point about datatypes, but conventional programming does not force you to state the type of your actual parameters, only the formal parameters. Why should an XML-based approach be different?

I know that we're actually suppose to discuss XML-RPC, but it is really only the obfuscation that separates it from SOAP, and I agree with previous posters that SOAP is likely to be adopted instead of XML-RPC because of industry backing.

Click here to validate:

• Slashdot's homepage
• This article

If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.

Mike

Click here to validate:

• Slashdot's homepage
• This article

If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.

Mike

Click here to validate:

• Slashdot's homepage
• This article

If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.

Mike

Click here to validate:

• Slashdot's homepage
• This article

If you're writing files by hand and prefer to upload them for validation from your local hard disk, try this form.

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

You might be interested in Dave Raggett's HTML Tidy, which is available from the W3C web site. It finds, reports, and fixes common HTML errors and produces valid HTML 3.2 or valid XHTML 1.0. It is available in C and Java versions.

There is a config-file setting that tells it to clean up Microsoft Word HTML output as well.

You might be interested in Dave Raggett's HTML Tidy, which is available from the W3C web site. It finds, reports, and fixes common HTML errors and produces valid HTML 3.2 or valid XHTML 1.0. It is available in C and Java versions.

There is a config-file setting that tells it to clean up Microsoft Word HTML output as well.

It's like the regular HTML, but we now have extra tags like:

• <TAUNT>
• <FLYING BUTTRICE>
• <CHAIRWHIP>

Uh, scotch that. "flying buttrice" won't fly as a tag name, as one can clearly see from the spec. The BNF (buttrice-naming form) clearly states that whitespace separates a tag name from an (optional) list of attributes or the final ">". Nobody wants a malformed buttrice. ;-)

It isn't just Microsoft's SOAP. There is an Apache implementation here. The spec has also been accepted by the w3c, and renamed to XP

I wonder what these people think about SOAP?

It seems as though this otherwise worthwhile project has hit an obstacle - it now conflicts with an alternative, open protocol for remote procedures based on XML. And when you've got two competing systems, the best one will win.

Unfortunately for XML-RPC, SOAP has the backing of a large proportion of the computing world, including both IBM and Microsoft. Whilst XML-RPC may be more in the "Unix spirit" it's a system that will be proprietary to Unix OSes rather than truly open.

And given the amount of backing that SOAP is getting, it seems as though XML-RPC will be left behind and slowly forgotten. I'm not saying this is a good thing, but unless it can offer something that SOAP can, then it will simply lose to a better system. And at the moment, I can't see how it can match SOAP, let alone better it.

Why the reference to the November 1996 Working Draft? Try the Recommendation instead.

Why the reference to the November 1996 Working Draft? Try the Recommendation instead.

Try reading the XPath TR. In contrast to the XSLT TR, it is very readable, concise, *and* precise.

Many cunning XSLT tricks depend upon a solid knowledge of the implicit coercions between types that XPath performs.

TBL said much the same thing.

ASN and XML (and that includes SGML) address different ends of the same problem, although they do overlap hugely.

ASN is a "wire protocol", and that's all it is. It takes some pretty low-level data typing concepts and describes a serialization for them. It's a very good serialization, and it's robust against a whole range of platform variables, but they just never lift their heads out of the trenches to look over the parapet.

SGML / XML are pretty low level too, but they're a whole level above ASN. Read the XML Infoset TR -- Can you imagine ASN describing that level of abstraction ? SGML (but not so much XML) let you deal with a bunch of structural issues by use of a DTD -- again, ASN would be left far behind.

I think you mean it is not a programming language.

XML = eXtensible Markup Language

It is a language. It has a defined syntax and semantics.

I could be wrong, but isn't that what Amaya is for?

If they're talking about not supporting Microsoft of Netscape extensions to HTML, I'm right behind them. But if they're talking about not supporting HTML-3.2, then screw them!

AFAICT, they're not. They're pointing out that it is not the old standards that are the problem, it's the old sucky implementations of these standards (or whatever they implemented) that we need to get rid of.

Now, I think this proposal is very radical, indeed, I think it might be too radical. However, if you design pages after the Web Content Accessibility Guidelines (which you should), the backward compatibility issues will be few, I think.

There are some very annoying things, like the font-size stuff in IE3. If I remember correctly, it scales the font relative to the default font of the element instead of relative to the parent element, which is what the spec says. Getting this incredibly bad browser out of circulation would of course be great. However, one needs to weigh the importance of using the font size extensively to the importance of getting IE3 out of the market.

Further, HTML4.01 Strict is a far better standard IMHO than HTML3.2. HTML3.2 was dictated pretty much by the panics that went on in the browser wars. HTML4.0 Strict gets back to the "separate style from content", which is a really Good Thing [tm]. HTML has a few problems, I think, mainly in the rather strange distinction between block level elements and inline level elements, but the separatation style from content is still something Good and Important.

And, BTW, WASP used Amazon as an example of sites that can't participate because they can't have a design that chase off a single user. Well, Amazon has a design which certainly chases me off as it is now...

If they're talking about not supporting Microsoft of Netscape extensions to HTML, I'm right behind them. But if they're talking about not supporting HTML-3.2, then screw them!

AFAICT, they're not. They're pointing out that it is not the old standards that are the problem, it's the old sucky implementations of these standards (or whatever they implemented) that we need to get rid of.

Now, I think this proposal is very radical, indeed, I think it might be too radical. However, if you design pages after the Web Content Accessibility Guidelines (which you should), the backward compatibility issues will be few, I think.

There are some very annoying things, like the font-size stuff in IE3. If I remember correctly, it scales the font relative to the default font of the element instead of relative to the parent element, which is what the spec says. Getting this incredibly bad browser out of circulation would of course be great. However, one needs to weigh the importance of using the font size extensively to the importance of getting IE3 out of the market.

Further, HTML4.01 Strict is a far better standard IMHO than HTML3.2. HTML3.2 was dictated pretty much by the panics that went on in the browser wars. HTML4.0 Strict gets back to the "separate style from content", which is a really Good Thing [tm]. HTML has a few problems, I think, mainly in the rather strange distinction between block level elements and inline level elements, but the separatation style from content is still something Good and Important.

And, BTW, WASP used Amazon as an example of sites that can't participate because they can't have a design that chase off a single user. Well, Amazon has a design which certainly chases me off as it is now...

I've never done a site which tried to sell stuff. For niche sites I use frames, funky graphics and Java, but make it easy to just get the plain text frame.

For political and other content sites I mostly focus on Nielsen's writings (ignoring his 1st law tho), with XHTML1 and CSS1.

I usually have a "Best viewed with a CSS1 capable browser" line on the meta page.

As a compromise between users who want to stick with their old browsers and designers who don't want all of their time stuck in a quagmire of old-browser esoterica, I'd suggest that the redirection page should be a plain-text version of the content, with a footnote note that compliance with certain standards is required to view the fancy web page.

I'd love to see this advice followed, but I am certain that it won't be.

It won't be followed, because of the amount of redundant content that needs to be maintained on the plain version of a site. First off, this automatically doubles the workload of the poor site designer who now has to maintain two (or more) versions of each page (I've worked with designers who have had sites to maintain with several thousand pages of static HTML). Secondly, you're bound to see errors and inconsistencies between versions, and the plain versions will likely get neglected, making them much less useful than a crippled version of the fancy page. From a marketing standpoint, maintaining these pages for a dwindling number of people using older browsers simply won't make sense.

It would be far better, I think, to put effort into making sure that the newer technologies fail gracefully when interpreted by older browsers. This has always been a design consideration with HTML, as well as frames, javascript, and CSS. It means that if you interpret an XHTML4+CSS page in an HTML2 browser, you should at least get something you can read, even if you miss out on the cool fonts and such.

HTML was designed in order to be able to separate content (in the html file) from presentation (in the browser). As long as we stick to this separation, then older browsers will automatically generate their own plaintext versions of your pages.

The article was not suggesting that we all move to cool, new, completely incompatible-with-html technologies like flash, which would leave older browsers completely lost, but just to stick to official W3C standards, which should at least be renderable by any browser out there.

This is not about graphic design. It's about the separation of style from content, which will allow us to do amazing things. Like redesign an entire site in hours instead of months. Stop authoring and debugging stupid, browser-specific markup. And support non-traditional browsers, from Palm Pilots(TM) to Braille readers, without building multiple versions of every page. All pretty good stuff.

Also, they make it clear that his move isn't for everyone. IE, big sites like yahoo and amozon. But they could still have a little link instead of redirecting.

In case you did hear me in a previous post, or didn't see the quote above. They are trying to make the web more acessable. Not trying to make sure that people can see neat/cool/flashy sites.

Maybe you should check out the following:

www.w3.org
www.webstandards.org
www.alistapart.com

Web Standards Project? Aren't W3C supposed to be in charge of web standards?

I am not sure I understand what you mean. /.'s HTML strikes me as pretty straightforward. It uses little or no CSS or JS. About the only complexities of it are some nested tables.

WEB BUILDERS: Tired of hacks and versioning? Write valid markup ...

The new W3C standards - HTML4 and CSS - make support for users with different physical abilities dramatically better. Why don't you go and educate yourself a little before you look like an even bigger fool?

question: is control controlled by its need to control?
answer: yes

I'll upgrade to something stupid and new IF everyone will pass the validator and Bobby. Until then they can go join the MS class action lawsuit against the evil "Open Software".

...and on top of that, you can validate your pages to these standards.

HTML Validator
CSS Validator

If I check good here... I'm done IMHO.

...and on top of that, you can validate your pages to these standards.

HTML Validator
CSS Validator

If I check good here... I'm done IMHO.

Second, sometimes it is rather handy just to fire up lynx to do a quick little errand, instead of waiting 30 seconds Netcrap 6.0 to come up.

Lynx does a good job of supporting most of the standards, actually. A standards-compliant site should work well in Lynx.

Third, how is this going to affect accessiblitiy for disabled people. Do the latest standards allow for this group of people to use the web?

Of course. That's one of the central purposes of having the standards at all. You can't hit WAI level AAA with old browsers except for the most basic, text-only sites. You need standards-compliant browsers and standards-compliant code to have images and multimedia and be fully accessible to the disabled.

The Project History and Credits section of the OpenSSH website would seem to refute your assertion:

OpenSSH is a derivative of the original free ssh 1.2.12 release from Tatu Ylönen. This version was the last one which was free enough for reuse by our project. Parts of OpenSSH still bear Tatu's license which was contained in that release. This version, and earlier ones, used mathematical functions from the libgmp library. That library was also included with these early ssh versions. The libgmp library is made available under the (LGPL) Lesser GNU Public Licence, although versions of that era were under the regular (GPL) GNU Public Licence.

Rapidly after the 1.2.12 release, newer versions bore successively more restrictive licenses, even though libgmp was still included and neccesary for using the software. Earlier restrictive licenses forbade people from making a Windows or DOS version. Later licenses restricted the use of ssh in a commercial environment, instead requiring companies to buy an expensive version from Datafellows.

The original license contained the following text:

As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell".

While I can't personally vouch for the veracity of the OpenSSH history, it and the original license not only seem to directly contradict your assertion that "you couldn't use it for commercial purposes", but also seems to imply that if a derived version of the original is compatible with the protocol description, then he has no problem with someone referring to it as "ssh" or "Secure Shell".

Also, The SSH transport and user authentication protocols have been submitted to the IETF by Ylönen himself, which I believe qualifies as "submit[ting] as an open standard". As a matter of fact, it's currently the main focus of the Secure Shell (secsh) IETF working group.

All in all, this parallels the "one click" scenario pretty closely, with the difference being that SSH was far more novel and complex an idea than "one click" shopping. If Mr Ylönen had released it as a commercial product, or even just released it under a more restrictive license, there would be no debate. As it stands, though, it reeks of dodgy business practices brought on by stockholder pressure and OpenSSH's success.

RDF is the Resource Description Framework, a W3C recommendation for making web content understandable by machines. Slashdot's own RDF is here. Cool, huh?!

A few composite replies to some of the statements that have been made here:

fleener wrote:
Either the W3C standards will change to somehow radically change the makeup of pages on-the-fly for blind users, or another Jakob Nielsen will rise to power and make a lot of money.

Actually, the W3C standard to change the makeup of pages on the fly exists; it's XSLT -- XSL Transformations. We use it at Reef (formerly Edapta) to do dynamic edaptations of the user interface to meet the needs of various audiences, including people with disabilities. If you want to see the semi-non-public demo pages from last year, drop me a note in email. (I'm not at liberty to get us slashdotted at the moment!)

Argy offered great advice, including:
As to what you're looking for, I'd spend some time browsing your sites using lynx.

If you haven't used Lynx for a long time, and don't want to bother to install it, you can also try Delorie's Lynx Viewer, a web-based lynx simulator script.

GC wrote:
You do not have to change your website at all. Your website does not define the media which will be used to define it. Your website will just send down the Internet pipe what it is requested for. The accessibility concerns are fully dependent on the equipment used to communicate and receive the information at the users end and this is not within your power nor should it be your concern.

I beg to differ here; it's a common fallacy that assistive technology can solve all of the problems of access. In fact, I included this on a list of Common Myths About Web Accessibility because many people seem to think that a screenreader or braille terminal can fix everything.

The problem, however, is a simple "garbage in, garbage out" scenario. Assistive technology needs enough information to be able to cobble together an alternate access method. That information is encoded within the HTML file. If the HTML file is poorly done, then it may prove impossible to get even the minimum information from a page.

If you don't want to simply believe me because I say it's so, then you could do a test yourself -- download a screenreader and try it out on a web page and see how it works. You may be disappointed to find that it's not as easy as you'd hoped -- and then remember that for many people this is their only way to access the web.

A few quick links to screenreader (or screenreader-like) technology:

1. IBM Home Page Reader 30 day trial, runs on Windows
2. emacspeak download from Sourceforge, runs on Emacs

Enjoy!

--Kynn Bartlett

Hi, Rafajafar -- I've met some of your web design team in the past, so I feel as if I "know" the JLAB.org folks in a way, and I've spoken with them about web accessibility, too.

I agree with you that this is a complex problem; Section 508 compliance is a major issue facing all federal agencies. The bad news is that if you haven't already been taking steps towards understanding web accessibility, you may be in a bit of difficulty. The issues surrounding access by people with disabilities are not new; this has been discussed for a number of years, and as others have stated, it really is just a part of basic, quality web design, not anything particularly extraordinary.

Unfortunately, while it's not all that hard to do it right, many people don't realize that, and many web sites, including federal sites, have accessibility problems.

Several great resources have already been posted on this thread, such as the Web Accessibility Initiative and CAST's Bobby web accessibility evaluator. Here's some others that might help you:

• The Section 508 FAQ by the Access Board
• Section 508 Unofficial Checklist, by my consulting company, IdyllMountain Internet
• HWG Online Course 201: Accessible Web Design , a 7-week course taught by me through the HTML Writers Guild's online education program

As you can see from the links I listed, I'm involved in helping to solve this problem in a number of ways -- including the work with my "day job" employer, formerly Edapta, now Reef to develop software that adapts a page to the user's requirements. If you need more information on this topic, you can drop me a note (but please, not all of you); full disclosure is that Idyll Mountain also does consulting on this very topic, but don't worry, I'm not going to hard-sell anyone my services.

At Reef recently I was asked to answer an editorial inquiry regarding this very question Rafajafar asked. Here's what I said:

The best strategies are threefold, and are based on past, present, and future:

1. Past: Old data represents the greatest challenge for web accessibility and section 508 compliance. Many thousands of web pages were created in a blatantly inaccessible manner, back before 508 requirements were created and before many people were aware of the issues. This means that there is a huge store of information which is inaccessible, but must be made accessible.

   This is primarily a resources problem; it takes time, energy, people-power, and money to convert those old pages into something which can be read by today's browsers, assistive technology, and database assimilation tools.

   In short, accessibility of legacy information is a problem akin to the Y2K problem. It consists of fixing problems which were caused by ignorance and poor programming practice; it is a simple problem in terms of complexity, but a time-consuming one.

   The ultimate solution is that those older documents must be updated in some manner. The most reasonable solution is to dump them into a database and make incremental repairs; there is no quick fix here to undo years of shoddy web design.

2. Present: Web development being completed now must adhere to the standards laid down by section 508 guidelines, and must include all information required by assistive technology devices. Web authors doing government work must immediately be retrained to understand concepts of platform independence and interoperability necessary to create accessible documents.

   This is an area in which I've been working for a number of years, first by creating and teaching an online course in web accessibility through the HTML Writers Guild (just completed the 11th run of the course!), and then by creating a resource center at the Guild, the Accessible Web Authoring Resources and Education Center. I've also conducted in-house seminars at locations such as Sandia National Laboratories, as well as given presentation at federal, state, and public conferences on web design.

   Education is the key to accessibility for any documents being produced today.

3. Future: In the future, the role of education will be reduced, because we will have tools which produce valid, accessible, usable HTML right out of the box -- something lacking currently in today's crop of WYSIWYG editors. But the web designer of tomorrow will have an even more potent tool at her disposal: Adaptive information delivery systems such as that being developed at Reef.

   Under such a system, web content creators and managers will be able to write once, web design artists will be able to design once per device, and the web morphing service and content edaptation service built into Reef will automatically produce any number of device-specific interfaces, from screenreader output to WAP phones; from interactive TV to braille terminals.

--Kynn Bartlett

As was previously noted, the rules apply to technology created/procured after mid-2001. But it wouldn't hurt to change what you've got anyway.

With thousands of pages, I'd write a program to read through all of them, labeling whether they seem to be okay as is, or if not list what elements may need work, the most common example being "add alt tags to images," but also audio or video files that could use transcription, server-side image maps, and that sort of thing. If all your html files are on one server, this is pretty easy, but you could also modify a web crawler to scan multiple servers. There are web-based checkers that do this sort of thing, including W3C's own HTML validator, but you'll probably want to write your own, dealing only with the issues you find really require changes.

As to what you're looking for, I'd spend some time browsing your sites using lynx. Navigation and comprehension doesn't have to be perfect, but it should seem basically usable. The W3's guidelines give all sorts of specific suggestions, but for the most part, browsing in lynx and applying common sense will obviate the areas that need work.

Some of JLab's pages are very visual, but most just need alt tags added. For pages that need changes, look at http://www.jlab.org, which has essentially one image cut into 30 GIFs to allow pretty mouse-over highlights on its links. There are essentially three choices for this sort of page.

1) Parallel pages. Put a "text-friendly version" link at the top, with a parallel, text-friendly version. This is only necessary for certain pages - keep links on the pages the same and just put alternate versions of each page as it's needed. And I wouldn't go text-only, just text-friendly....

2) Text-only makeover. Redo the page to cut out the unnecessary graphical frills you put so much work into creating, thereby having *only* a text-friendly version.

3) Dual-use makeover. Redo the page to use unnecessary frills, but with text-friendliness in mind as well. This doesn't really take any more work than the doing a text-unfriendly design, but since you're doing it over, text-unfriendly design, but since you're doing it over, it's certainly a hassle.

Ultimately I think dual-use, accessible design is what the legislation in question is trying to encourage.

I am currently working on a US government web site. (OK, it's a state web site, but they are holding us to the federal rules because they know they're next...) Here's some practical advice:

1. Read the W3 Accessibility Initiative to get an idea of the concepts of making the web accessible. Contrary to popular opinion, the web is for everyone.
2. Use Bobby, a free automated tool written in Java that can check your entire site for accessibility problems. It categorizes problems based on priority level, checks pretty much everything listed in the WAI, and tells you what you still have to check manually that it can't check automatically.
3. Read the W3 Techniques for Web Accessibility to get an idea of how to implement the changes. Contrary to popular opinion, HTML 4 has many features specifically for blind/deaf/disabled users.
4. Test your site yourself. Use Lynx to see what your site looks like to the blind. Do all your images have meaningful ALT tags or LONGDESC tags? Do your tables have SUMMARY tags? Is your navigation usable without Javascript or Flash?
5. Set your text size to maximum to see what your site looks like to visually impaired users. You are using relative sizes for your fonts and percentages for your table widths, aren't you?
6. Turn off your speakers to see what your site looks like to the deaf. If you have audio feeds, do you also have transcripts? If you have video feeds, are they closed-captioned?

It's not rocket science once you know what you're doing. Personal anecdote: I applied the same principles to my own web site, even though I didn't have to and my friends told me I was wasting my time because "nobody uses Lynx anymore." In the first week, I got 10 Lynx visitors.

-M

You're smart; what haven't you learned Python yet? http://diveintopython.org/

I am currently working on a US government web site. (OK, it's a state web site, but they are holding us to the federal rules because they know they're next...) Here's some practical advice:

1. Read the W3 Accessibility Initiative to get an idea of the concepts of making the web accessible. Contrary to popular opinion, the web is for everyone.
2. Use Bobby, a free automated tool written in Java that can check your entire site for accessibility problems. It categorizes problems based on priority level, checks pretty much everything listed in the WAI, and tells you what you still have to check manually that it can't check automatically.
3. Read the W3 Techniques for Web Accessibility to get an idea of how to implement the changes. Contrary to popular opinion, HTML 4 has many features specifically for blind/deaf/disabled users.
4. Test your site yourself. Use Lynx to see what your site looks like to the blind. Do all your images have meaningful ALT tags or LONGDESC tags? Do your tables have SUMMARY tags? Is your navigation usable without Javascript or Flash?
5. Set your text size to maximum to see what your site looks like to visually impaired users. You are using relative sizes for your fonts and percentages for your table widths, aren't you?
6. Turn off your speakers to see what your site looks like to the deaf. If you have audio feeds, do you also have transcripts? If you have video feeds, are they closed-captioned?

It's not rocket science once you know what you're doing. Personal anecdote: I applied the same principles to my own web site, even though I didn't have to and my friends told me I was wasting my time because "nobody uses Lynx anymore." In the first week, I got 10 Lynx visitors.

-M

You're smart; what haven't you learned Python yet? http://diveintopython.org/

The w3 has been talking about this for years. The Web Accessibility Initiative is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines, checklists, and techniques sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan

The w3 has been talking about this for years. The Web Accessibility Initiative is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines, checklists, and techniques sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan

The w3 has been talking about this for years. The Web Accessibility Initiative is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines, checklists, and techniques sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan

The w3 has been talking about this for years. The Web Accessibility Initiative is their site dedicated to exactly this issue, and is rich in information and resources for implementation. See particularly the guidelines, checklists, and techniques sections.

You do have a lot of work ahead of you. It's much easier to start with accesibility in mind than to retro-fit everything. You might be able to script some of it, as others are suggesting, but your first step should be to thorougly familiarize yourself with the information at the WAI.

TomatoMan