Slashdot Mirror

Nobody's mentioned the implicit validation that you get by using a type-specific de-serializer that's been generated from XML Schema definitions, eg as part of NET or Java support for Web Services. This may actually be faster than using a non-validating browser (not that I've timed it).

I have been generating a C# client from WSDL generated by a Java Web Service tool, and it just works.

XML Schemas may be complex and intimidating, but once they've been automated out of the way they're great.

It would be somewhat unfortunate if both end up popular, because it will be more work to maintain both sets of tools than either one alone.

That's only partly true. Relax NG is mainly about structural validation (what elements and attributes are allowed in what elements) but it is designed to permit any implementer-supported simple type (non-structural content: string, dates, numbers, reg-exes etc) validation system using the datatypeLibrary attribute.

An obvious candidate for this is the conveniently modularised XML Schema Simple Types. This could be fruitful - the XML Simple Types are comprehensive and complex, and have some critics, but they are less controversial than XML Schema Structures.

It would be somewhat unfortunate if both end up popular, because it will be more work to maintain both sets of tools than either one alone.

That's only partly true. Relax NG is mainly about structural validation (what elements and attributes are allowed in what elements) but it is designed to permit any implementer-supported simple type (non-structural content: string, dates, numbers, reg-exes etc) validation system using the datatypeLibrary attribute.

An obvious candidate for this is the conveniently modularised XML Schema Simple Types. This could be fruitful - the XML Simple Types are comprehensive and complex, and have some critics, but they are less controversial than XML Schema Structures.

HTML is a subset of XML - an alternative to the bloated XMl language.

believe me, you wont use XML (and those pesky XSLTs) anymore if you once tried HTML

AND (most importantly) in virtually every single web browser that you can find, support for viewing this format over the internet is available and built into the browser itself!

HTML is a subset of XML - an alternative to the bloated XMl language.

believe me, you wont use XML (and those pesky XSLTs) anymore if you once tried HTML

AND (most importantly) in virtually every single web browser that you can find, support for viewing this format over the internet is available and built into the browser itself!

The Schema WG decided on "schemas" so as not to add unexpected obscurity to the specification.

See this message.

Expected obscurity is of course just fine.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

In my experience, many benefits of XML come when dealing with the presentation layers of many application architectures, with the ability to repurpose syndicated data at wil, here are a few examples:

• RSS which defines an easy standard for any site to provide "News" in a well-defined XML Format. This allows developers to write software to aggregate news from different sites into one convenient interface, sites to exchange news headlines with eachother.
• Google Web APIs which allow developers to create their own custom google-powered search site with their own look and feel by simply proxying a user's search query to the google server which returns search results in XML data which can subsequently be transformed in HTML before being sent back to the user via various processes such as an XSLT transformation.
• Amazon Web API, similar in principle to the above Google API, allows developers to enhance their sites by allowing their users to search for Amazon products without having to go the Amazon site itself. One interesting side-effect of such API is that an Amazon competitor, say Barnes and Noble, could offer a similar API to their own site. Now I could allow my users to use my service to search for books and offer them results and price comparisons from both Amazon and Barnes and Noble

Effective use of XML and XSLT allows you to easily aggregate informational data from one or multiple sources and "repurpose" for an infinite variety of business and technological goals.

One of the main benefits of XML is that it offers and effective, textual representation of "scructured data", that can be conveniently accessed and manipulated according to a slew of various surrounding standards such as XPath, DOM, XSLT, namespaces.

Of course, this was roughly contemperaneous with Tim Berners Lee's development of the WWW so both factors probably worked together towards making the 'net what it is in this day and age.

Not exactly. The Boucher Bill was passed in 1993; TBL invented the WWW in 1991 (the first work was in 1989; the publication of the CERN httpd was in 1991, though, and that publication - particularly these emails, dated 9 Aug 1991, offering the code for free and providing the first public http links I know of - should constitute the birth of the WWW.

What the Boucher Bill did was provide a policy framework for the public Web/Internet as we know it. Still worthy of mention in the annals of history, regardless of how Algore might have [mis?]characterized it.

Of course, this was roughly contemperaneous with Tim Berners Lee's development of the WWW so both factors probably worked together towards making the 'net what it is in this day and age.

Not exactly. The Boucher Bill was passed in 1993; TBL invented the WWW in 1991 (the first work was in 1989; the publication of the CERN httpd was in 1991, though, and that publication - particularly these emails, dated 9 Aug 1991, offering the code for free and providing the first public http links I know of - should constitute the birth of the WWW.

What the Boucher Bill did was provide a policy framework for the public Web/Internet as we know it. Still worthy of mention in the annals of history, regardless of how Algore might have [mis?]characterized it.

There are Flash players for various models of cellphones and PDAs already, and more in the works.

The devices that Flash is deployed upon (e.g. Nokia's 9210 Communicator, soon) are much more hefty than the ones SVGt is being optimized for (e.g. Nokia's 3650 and 7650). Furthermore, SVG is being sold with the platform, such as TI's OMAP chipset platform. That chipset has a huge percentage of the cell phone market.

And Flash MX supports what Macromedia calls "assistive technologies functionality."

Nevertheless, SVG's markup-based, HTML-integrated syntax is much better optimized for accessibility.

Flash's licensing model is inherently anti-accessibility because it does not allow the creation of competitive "viewers" including viewers optimized for blind people. SVG is not so-encumbered.

Seems to me a Web page designer who can embed alternate XHTML code would find it trivial to implement a Javascript or other server-side check for the presence of the Flash client, then "degrade" to static pages as needed.

Those are the kinds of hacks that make the Web much less easy to index, download and otherwise manipulate. Scripting is a fallback, to be reserved for exceptional tasks.

Even if SVG becomes a widespread standard, I could imagine a lot of pages checking for Flash first, then "degrading" to SVG -- because Flash files are compressed binaries, far smaller than the equivalent SVG.

SVG files can also be compressed binaries. GZIP compression is a required part of the specification. That's the better way to do binary compression because almost every language and platform has a gzip implementation.And because they use mathematical animation rather than frame-based animations, they will often be smaller than Flash files. Try again!

To me, the issues are clear. Flash has a much better existing toolbase and a much larger deployed audience. SVG has a much stronger technical architecture and is achieving rapid uptake in all sorts of verticals. It will take years for SVG to seriously challenge Flash. But when it does, SVG will win because its technology is so much stronger and it is a true standard which already has literally hundreds of cooperating tool implementations for every language, platform and application and will have thousands in the not-too-distant future.

There are Flash players for various models of cellphones and PDAs already, and more in the works.

The devices that Flash is deployed upon (e.g. Nokia's 9210 Communicator, soon) are much more hefty than the ones SVGt is being optimized for (e.g. Nokia's 3650 and 7650). Furthermore, SVG is being sold with the platform, such as TI's OMAP chipset platform. That chipset has a huge percentage of the cell phone market.

And Flash MX supports what Macromedia calls "assistive technologies functionality."

Nevertheless, SVG's markup-based, HTML-integrated syntax is much better optimized for accessibility.

Flash's licensing model is inherently anti-accessibility because it does not allow the creation of competitive "viewers" including viewers optimized for blind people. SVG is not so-encumbered.

Seems to me a Web page designer who can embed alternate XHTML code would find it trivial to implement a Javascript or other server-side check for the presence of the Flash client, then "degrade" to static pages as needed.

Those are the kinds of hacks that make the Web much less easy to index, download and otherwise manipulate. Scripting is a fallback, to be reserved for exceptional tasks.

Even if SVG becomes a widespread standard, I could imagine a lot of pages checking for Flash first, then "degrading" to SVG -- because Flash files are compressed binaries, far smaller than the equivalent SVG.

SVG files can also be compressed binaries. GZIP compression is a required part of the specification. That's the better way to do binary compression because almost every language and platform has a gzip implementation.And because they use mathematical animation rather than frame-based animations, they will often be smaller than Flash files. Try again!

To me, the issues are clear. Flash has a much better existing toolbase and a much larger deployed audience. SVG has a much stronger technical architecture and is achieving rapid uptake in all sorts of verticals. It will take years for SVG to seriously challenge Flash. But when it does, SVG will win because its technology is so much stronger and it is a true standard which already has literally hundreds of cooperating tool implementations for every language, platform and application and will have thousands in the not-too-distant future.

It is a web borwsing platform. Just as desktop applications are built on an operating system, so are web sites built on browsers.

Real websites are built to standards, not on browsers that occasionally take liberties with those standards.

So one cannot expect that a web site will work in the same way on all browsers.

Why not? A site that works fine in $BROWSER_X but is a mess in $BROWSER_Y is a pretty sh*tty website. I'm not claiming that a site will render identically between two browsers...compare Mozilla for Win32 and Mozilla for Linux (the latter tends to choose font sizes that are too small). However, identical rendering isn't even the stated goal of HTML. (It's somewhat addressed by CSS, but even there you should expect some variability.) It is not at all unreasonable to expect a website to be functional when accessed with any browser. The path you'd take would only lead to further balkanization of the Web.

In 2002, A Danish court made an injunction preventing a Danish news filtering service (effectively a sort of search engine) from linking to pages of a Danish newspaper. See the slashdot article. I assume that the appeals process will clear up this after this time of writing (2002/07). If such decisions are accepted, the whole working of the web would break down.

I haven't been able to dig up more on the story. How are the appeals going, for example? I'm not sure it is a good idea to route around the court before you have gone through all possible appeals, especially since they've got TimBL on their side.

I feel developers should always try to be as aware as possible about the technologies they use, without bias. Sometimes a client may request something be done in Flash, other clients may require that everything be as XML conformant as possible. Whatever the request, the developer needs to be aware of the pluses and minuses of each, and inform the client where need be. Flash has it's place, especially as Macromedia is putting in effort with MX to get it to address accessibility issues.

There is another possible advantage to SVG, being XML compliant, that I have not seen addressed here, and that is SVG media/documents can be formatted on the fly, using XSLT for various media. CSS addresses media types for (I know the support for all is not there yet, but it is getting there)

• screen
• print
• projection
• handheld
• tty
• tv
• aural
• braille
• emboss

I saw Dean Jackson's presentation at the OzeWAI 2002 Conference. From what I could see, he was using Mac OSX, and Python XSLT tools to produce his PowerPoint like SVG slides. In this format, one should be able to configure completely different behaviour, look and feels for any of the desired end media formats. Without a file format based in structured markup, this becomes much more difficult to address. For this purpose, this is far more flexible.

I do feel that as/if SVG is eventually built into browsers natively, there will need to be some user configurability to control the behaviour of the SVG, (and other media) in the browser. If there are animations the user needs to be able to easily turn them off (if they want too), or allow the user to turn them off by default. Users obviously want this type of control as each user is different, some may love animated web pages, others may not. SVG and user-agents need to be easily configurable and controllable. This should be pretty obvious given Mozilla's and Opera's preferences to allow the user to manage the DOM, and the market in Popup blockers for IE that manage the DOM and http refreshes and the like.

As a side note, I really do not think the W3C is trying to box in/out developers. I try to follow most of the discussion groups associated with Web Accessibility Initiative (WAI). I can see how it would be easy to form the mistaken opinion that this bunch of people basically want a web driven by Lynx (or some really bland HTML). I ask those of you here that find the process of the W3C draconian, to just follow any of the active W3C discussion lists. I find a community of people that, for one have taught me a lot about how to work as a collaboration of people with different views and agendas, that are working with everyone to try and find a way to present the web in the most universal and open standards. There is often very healthy debate, and many people trying and working very hard not to limit the standards. The W3C is not the Web Police, it's just a standards body trying to build an equitable, accessible web (Maybe I'm really naive).

Admittedly they do not do such a good job of marketing themselves and educating developers, but it is a democratic process, if you really don't like something and feel you have better solutions, or can improve, or help, join a working group and help improve the web.

If you do follow a discussion list for a few months, and do not find what I stated, well.. you can email me a tell me what a flamin idiot I am (you may not be far wrong).

I feel developers should always try to be as aware as possible about the technologies they use, without bias. Sometimes a client may request something be done in Flash, other clients may require that everything be as XML conformant as possible. Whatever the request, the developer needs to be aware of the pluses and minuses of each, and inform the client where need be. Flash has it's place, especially as Macromedia is putting in effort with MX to get it to address accessibility issues.

There is another possible advantage to SVG, being XML compliant, that I have not seen addressed here, and that is SVG media/documents can be formatted on the fly, using XSLT for various media. CSS addresses media types for (I know the support for all is not there yet, but it is getting there)

• screen
• print
• projection
• handheld
• tty
• tv
• aural
• braille
• emboss

I saw Dean Jackson's presentation at the OzeWAI 2002 Conference. From what I could see, he was using Mac OSX, and Python XSLT tools to produce his PowerPoint like SVG slides. In this format, one should be able to configure completely different behaviour, look and feels for any of the desired end media formats. Without a file format based in structured markup, this becomes much more difficult to address. For this purpose, this is far more flexible.

I do feel that as/if SVG is eventually built into browsers natively, there will need to be some user configurability to control the behaviour of the SVG, (and other media) in the browser. If there are animations the user needs to be able to easily turn them off (if they want too), or allow the user to turn them off by default. Users obviously want this type of control as each user is different, some may love animated web pages, others may not. SVG and user-agents need to be easily configurable and controllable. This should be pretty obvious given Mozilla's and Opera's preferences to allow the user to manage the DOM, and the market in Popup blockers for IE that manage the DOM and http refreshes and the like.

As a side note, I really do not think the W3C is trying to box in/out developers. I try to follow most of the discussion groups associated with Web Accessibility Initiative (WAI). I can see how it would be easy to form the mistaken opinion that this bunch of people basically want a web driven by Lynx (or some really bland HTML). I ask those of you here that find the process of the W3C draconian, to just follow any of the active W3C discussion lists. I find a community of people that, for one have taught me a lot about how to work as a collaboration of people with different views and agendas, that are working with everyone to try and find a way to present the web in the most universal and open standards. There is often very healthy debate, and many people trying and working very hard not to limit the standards. The W3C is not the Web Police, it's just a standards body trying to build an equitable, accessible web (Maybe I'm really naive).

Admittedly they do not do such a good job of marketing themselves and educating developers, but it is a democratic process, if you really don't like something and feel you have better solutions, or can improve, or help, join a working group and help improve the web.

If you do follow a discussion list for a few months, and do not find what I stated, well.. you can email me a tell me what a flamin idiot I am (you may not be far wrong).

Other posts in this thread have listed some disadvantages of SVG, but omitted that a browser plug-in fully implementing the spec weighs in at several megs.

Last time I built Amaya it only weighed in at several megs itself -- and it's a browser, WYSIWYHYGOOB (What You See Is What You Hope You Get On Other Browsers) XHTML editor, and to the best of my knowledge, fully supports SVG and MathML (which although unrelated, is nice if you don't have LaTeX2HTML or HeVeA handy).

Version 4 of Adobe SVG Viewer (renamed Adobe Image Viewer) also supports synchronization of video elements. Unfortunately Adobe Image Viewer only supports viewing SVG files that are embedded in Acrobat PDF files.

In theory, it is a good idea, but it is only "widely accepted" (pronounced: "anticipated") by programmers who have been talking trash about Flash usability and want to play with vector art without losing face.

SVG has wide usability and even popularity in tasks far beyond Flash's ability. For instance SVG is the standard display format for geographical applications. SVG is used for some scalable KDE icons. SVG can be natively produced using open source software on open source operating systems. SVG is going to be embedded in the next generation of cell phones. SVG is going to be embedded in upcoming printers as a page description language. It is possible to print to SVG as you might print to Postscript or PDF. It is also possible to directly render PDF to SVG. And you will soon be able to output Visio diagrams as SVG. I've even heard of an SVG front-end for NetHack.

The point is that SVG can achieve popularity much greater than Flash's without displacing a single Flash animation. And once it has done that, it will be a small additional step to wipe Macromedia's proprietary, binary crap off of the face of the earth. ;)

By all means, use Flash for the time being. It is the best tool for many jobs. But don't think that SVG is a "theory." It is used by thousands of people in practice, in both commercial and open source projects. There are many businesses dedicated to building SVG tools, and whole industries being re-imagined around SVG. Its recent growth curve is amazing and I'm convinced it will be remembered as being as important as other major W3C specs such as XML and HTML before it.

SVG is not intended to do synchronized multimedia. The G in SVG stands for "Graphics". If you want to build an all-out presentation with animation and audio, use SMIL in conjunction with SVG (or whatever you want for the graphics/animation side).

We received a 40 page package from SBC Intellectual Property today informing us that our web site - which has links on the left side that go to other web pages within the site - but does not lose the left side navigation links - was in violation of their "Structured Document Browser" Patent.

http://www.w3.org/Graphics/SVG/SVG-Implementations .htm8#svgedit

Most vector graphics packages nowadays have the ability to export SVG as well.

It's worth noting that the cited patent is dated 3rd August, 1999, nearly two years after the 1997 release of the W3C HTML 4 specification, which added, among other things, support for frames in HTML.

SWF - Propietary format, but easy to make via wizards and so forth for the 16 year old web designer in your neighborhood. Flash 5/MX easily warezed which nullifies some cost concerns fro the less scrupulous. Well known.

SVG - Free format, but requires a foreknowledge of XML. Well supported by the mobile industry and some pretty heavy hitters, but not particularily known by the public.

Will both be implemented equally or will one ever edge out the other? Are we really going to have to suffer through Flash for much longer?

That should read:

The W3C has just released Scalable Vector Graphics (SVG) 1.1 and Mobile Scalable Vector Graphics (SVG) 1.1 as W3C Recommendations.

That should read:

The W3C has just released Scalable Vector Graphics (SVG) 1.1 and Mobile Scalable Vector Graphics (SVG) 1.1 as W3C Recommendations.

presumably you are already a member

Otherwise they way they conduct their business is kind of none of your business.

If you had ever read HTML 4.01 spec fully you would have noted how it suggested that object element should be used for all embedded objects. To quote w3c:

For example, to include a PNG image in a document, authors may write:

<BODY> <P>Here's a closeup of the Grand Canyon: <OBJECT data="canyon.png" type="image/png"> This is a <EM>closeup</EM> of the Grand Canyon. </OBJECT> </BODY>

Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:

• They fail to solve the more general problem of how to include new and future media types.
• The APPLET element only works with Java-based applets. This element is deprecated in favor of OBJECT.
• They pose accessibility problems.

And now they have removed IMG and APPLET. Are you surprised?

About what comes to CITE, as many already noted that was simply an authoring mistake while making the draft and it has already announced on the mailing list that it'll be back in the next draft.

I think that anybody that says h1-h6 should be kept instead of SECTION and H elements doesn't simply know what she is talking about. The problem with Hx is that one can skip levels. If the headers were numbered by default it would be highly visible. I know many slashdotters do start their web page with H3 simply because "it looks better than that god-awful-huge h1". If the first header said "1.1.1. I'm the first header" even an idiot author would think something smells fishy. In addition, there's no way to tell where one section of document ends. They new way is to enclose sections inside SECTION elements. Those sections can be nested and section can contain header enclosed in a H element. Browser then uses the nesting depth of SECTIONs what enclose a single H element to decide the size the header should be rendered at.

Example:
<section><h>header1</h>foo
<section><h>header2</h>bar</section>
baz</section>

Note that "baz" belongs to logical section named "header1". You cannot represent a structure like this with H1-H6.

One possible rendering could be:
header1
foo
| header2
| bar
baz

But the truth is, this all really doesn't matter. People will continue to author HTML3.2, stick XHTML2 DOCTYPE identifier and serve the documents as text/plain, regardless of what the possible final spec will say. And they will complain if their cool frameset doesn't work. Those few of us who care to follow the recommendation can easily do it. Simply change those few remaining IMG elements to objects and upgrade your document structure to SECTION and H and you're pretty much done. If you feel adventureous you could start authoring XHTML2 pages immediatly and simply write the missing rendering instructions in the user stylesheet. Yeah, it might work in Mozilla only, but that can be used for testing and as a real world prototype.

If you want to bitch about something it should be that XForms are too complex, but anything is better than current HTML forms.

ADDRESS (was this suppoed to be email or postal or both? It's ambiguity destroys any semantic value).

Neither. How about you read the specification? It certainly doesn't seem very ambiguous.

The word standard implies that it is unwaivering and uniform. XHTML is most definitely NOT that!
oops, just used a <br />

Damnitall, well be seeing websites with HTML 4.0 forever.
Microsoft, Mozilla, Opera, Kde, etc., etc.. Screw the interface of your browser! Just get the dammed thing to display pages consistently with the law of the internet!
Then again, the law has no teeth, you abide because "you're supposed to."
Or that's what I get from it at least.

• acronym tag is gone

It was always misused anyway. An acronym is pronouncable.

• q tag is gone

...replaced with the <quote> element.

• cite tag is gone

...which was an editing mistake.

• img tag is gone (yes, really!)
• applet tag is gone (also really!)

They were only special cases of the <object> element anyway, which is still there, and far more flexible.

• br tag is deprecated

...in favour of the <line> element, which is much more in line with the fact that xhtml is a markup language and not a programming language.

• h1 thru h6 are deprecated

...because a single <h> element in the context of <section> elements is far more flexible.

Remember, they are called elements, not tags. The tags are the funny things in angle brackets, elements are the whole things.

The question remains, why are there deprecated elements in a non-backwards compatible markup language?

I am highly skeptical of things like this because it seems to just be microsoft attempting to control an xml based data language as a reaction to a similar open language, xquery, being developed by the w3c.

I'm not pro-ms, but it's not as simple as that. MS has many apps, departments and policies. As for IE meeting standards, the Windows versions are still getting there, but are pretty good, but they do have some bugs, shortcomings in HTML, CSS, and especially DOM. But some credit must go to the Mac programmers at MS who built one of the most standard compliant versions of IE (5.5).

From what I can gauge, the adherence to standards in MS, or any large company often has a lot more to do with departmental leadership, agendas and politics, rather than overall company policy.

MS deserves credit for making their OS and API supportive of accessibility assistive technologies, but they still have a way to go. As a side note, their main accessibility page, (and probably all the rest of them) has never validated.

Improved standards compliance for IE6 (they seemed to have missed the new support for DTDs in this list).

Do you understand that caching websites without the author's permission is illegal?

I apparently know a little more about HTTP than you seem to, my friend. If it were illegal to cache HTTP resources, then most HTTP proxies are illegal as well.

There is no standard HTTP mechanism for caching

Uhh, OK. RFC2616 section 13 seems to disagree with you.

copying the page and giving it off as yours would surely spark many lawsuits.

If a site is expressing a future date in an HTTP "Expires" header, or a max-age Cache-Control header, they're saying something very specific about how that data can be used by browsers and HTTP proxies alike. Read the document above to what it is.

At the very least, this is lazy

What?? Just because I choose to post some data online does not mean that I must automatically spend the money to create an environment and supply a network connection capable of withstanding a post on Slashdot. This reasoning is flawed. Most people with smaller web sites (e.g. academic) do not have the funds to do this. You seem to be under the flawed impression that any server with any form of network connection should be capable, with proper administration, of handling the traffic that a post on Slashdot generates.

This is like saying that people who are victims of distributed denial-of-service attacks get what they deserve for not having a fast enough network connection or a router that can do a better job of filtering packets. This is a totally unreasonable expectation. Sure, they "deserved" network traffic by placing their servers and networks on the Internet, but they're not lazy just because they choose not to spend the money for an enterprise-quality network when it's horribly out of scale for their requirements.

If you don't lock your front door, you shouldn't complain about burglars.

I can't even begin to touch this analogy.

I would be glad for the extra publicity, not bitchy about the traffic.

I'm sure that somewhere, deep down under his annoyance, he is.

Are you going to sit there and honestly say that if a web site you operated were brought to its knees and made totally unavailable due to a post on Slashdot, it would not have irritated you? "Aww shucks, I should have planned ahead better and gone with that Sun E5500 instead of this P133 after all! How stupid of me for not spending a half a million on infrastructure for my personal home page instead of this extra PC." Get real.

I do concede, though (as I have in previous posts), that he should not have been surprised this would have happened one day. And maybe he was aware that it could happen one day, and maybe he even planned ahead in the sense that there might have been some people willing and able to mirror his site's content at his request. If only he had some advance notice.

If, on the other hand, Slashdot mirrored my site without asking permission, I would be somewhat pissed.

If you are expressing the cacheability of resources on your web site incorrectly, then you are to blame here. Set up your cache control headers in your web server to more accurately describe how each resource could be cached. If you seem to think that every request should go back to the server and get re-retrieved, and that HTTP 304 responses are the devil, then by all means, just configure your web server so that it won't allow it. The point is, the site owner can make this decision (and should already be making it).

Please don't assume that everything you read on Slashdot is factual. Concede the possibility that the stuff in the FAQ is written by human beings who are fallible.

This is RAND licensing, folks. The same fine mess the W3C wants to get into.

Oh really?

You can ignore this comment... just testing something (Learning HTML - yep finally getting to it). Here's some reading material. :)

Microsoft decided to not provide an UI to define default font size in the Internet Explorer. Consider this being equivalent to a TV set without an option to adjust volume. Some web "designers" feel that they have to compensate the fact that the MS engineer decided to specify "too large" default font size.

I'm so SICK of hearing people bitch about this. Maybe you morons should use a different browser if your current shitty one doesn't support such rudimentary features.

Uh? Perhaps you should reread my post? The word "some" doesn't include me. You might be speaking about yourself in 3rd person but I don't do that. I was bitching about the fact that because MSIE is buggy and it has many users some web "designers" feel that they must break some rules to make a web page to compensate some of those bugs. Nevermind the fact that those "fixes" break any standards-compiliant browser. I don't use MSIE, I don't support it and I always try to code according to the recommended spec--but there're many others doing something else.

According to these standards.

Poster: If it didn't register itself as Netscape 5 or something with a modicum of site compatibility site scripts would redirect it to the retard text only version of a site.

Me: If everyone coded according to the standards instead of using browser-specific hacks, its user-agent string wouldn't matter (except for logging, etc.).

This choice sounds utterly insane to me. With the greatest respect, khtml is nowhere near as good as Gecko in terms of it standards support or behaviour or stability especially when dealing with some of the crap sites out there in the world. Run it through a few random sites involving nested tables, CSS or frames and it quickly screws up rendering.

Well, I'd noticed it seemed to be doing okay on most CSS pages I'd tried, so I was *going* to say, "nyah, nyah", but then I figured I go to the ever-useful CSS1 test suite pages.

Oops...on the very first test, it fails to display even the test page correctly and the dialog tells me it's choking on the illegal mimetype text/html. Very ungood.

Well, it's beta, and Apple has never seen a wheel it didn't want to re-invent at some point...

Amaya has annotations buit in.

While I'm not about to start using amaya to surf the web and post to /. - it's fun to play with things liek the annotations. They can be stored on a remote server and shared apparently, but I've not tried that yet. All in all - I think it looks just liek what the posted was asking for.

ok, first of all - I'm not all that familiar with this - but here goes anyway. there is a W3 project called Annotea It is implemented in Amaya as annotations, which apparnelty can be stored on a remote server. It uses this RDF annotation schema and stored on a remote annotation server (the annotation server howto)

When you have created an annotation for a piece of text, there is a pencil icon next to it. Click it and the annotation appears as a popup. It appears to be a very nice concept - but I've not used it much. I assume that teh annotations could be presented inline in the document.

ok, first of all - I'm not all that familiar with this - but here goes anyway. there is a W3 project called Annotea It is implemented in Amaya as annotations, which apparnelty can be stored on a remote server. It uses this RDF annotation schema and stored on a remote annotation server (the annotation server howto)

When you have created an annotation for a piece of text, there is a pencil icon next to it. Click it and the annotation appears as a popup. It appears to be a very nice concept - but I've not used it much. I assume that teh annotations could be presented inline in the document.

ok, first of all - I'm not all that familiar with this - but here goes anyway. there is a W3 project called Annotea It is implemented in Amaya as annotations, which apparnelty can be stored on a remote server. It uses this RDF annotation schema and stored on a remote annotation server (the annotation server howto)

When you have created an annotation for a piece of text, there is a pencil icon next to it. Click it and the annotation appears as a popup. It appears to be a very nice concept - but I've not used it much. I assume that teh annotations could be presented inline in the document.

...it would have been more tolerable had he not felt the need to comment on fucking everything...

For those who wish to read only the original content, you can use CSS to disable the comments by putting the following rule in your browser's user style sheet:
.comment { display: none; }

In Mozilla, this means adding the above line to $HOME/.mozilla/profile name/random salt/chrome/userContent.css and restarting your browser. The same can also be achieved in Opera.

Admittedly it's a little much to make these changes for just one Web page, but as more Web pages start to use CSS, this sort of thing will hopefully apply to more than just one or two pages. Alternatively, you could contact ESR and suggest he provide an alternate stylesheet so you can easily toggle comment display.

...it would have been more tolerable had he not felt the need to comment on fucking everything...

For those who wish to read only the original content, you can use CSS to disable the comments by putting the following rule in your browser's user style sheet:
.comment { display: none; }

In Mozilla, this means adding the above line to $HOME/.mozilla/profile name/random salt/chrome/userContent.css and restarting your browser. The same can also be achieved in Opera.

Admittedly it's a little much to make these changes for just one Web page, but as more Web pages start to use CSS, this sort of thing will hopefully apply to more than just one or two pages. Alternatively, you could contact ESR and suggest he provide an alternate stylesheet so you can easily toggle comment display.

This isn't "2, Insightful", it's "-17, Wrong". Everything needs to be in the RAM to work. Doesn't matter if it's a cache (ie, not being currently used) or "active" memory (ie, currently being used). If your system is infected with a worm that can access any area of its RAM, then it doesn't matter if (from the browser's point of view) that area is part of the RAM cache or any other part. Not only that, but history operations (back, forward) are supposed to be cached (read RFC2616, scroll to the bottom).

Why do moderators rate posts about subjects they clearly don't understand? Don't mod something as "insightful" or "informative" unless you know it's really true. For those moments when you think something sounds interesting but don't have any personal knowledge about it, just rate it as "Interesting", and let other people reply.