Slashdot Mirror

Web bugs are more evil than your average URL link because you have to click on the link, whereas a web bug (and the potential attached evil code) gets loaded automatically if you have an HTML-enabled mail viewer. Stuff like this is why I have intentionally avoided HTML-enabled mail clients. Automatically executing code from a remote, untrusted source is bad, kids.

HTML email gets a bad wrap. The thing people forget about HTML is that it is, at its core, a semantic markup language. HTML provides meaning to otherwise flat text. Flat text forces the author of an email to use how an email will look to get across meaning. On the other hand, HTML clients, done properly, allow the reader to decide how something will look.

My dream is to have an HTML-aware client that accepts everything that is in the XHTML-Basic specification. XHTML-Basic allows basic semantic markup, disallowing presentational elements such as <font>, and uses CSS to provide presentation. However, the client can choose to ignore the CSS, if the user wants, leaving all presentational items up to the reader.

In summary, plain, flat text for mail is one of the worst things we are plagued with. It mixes meaning with presentation. The author is forced to decide presentation, which is one of the biggest evils of communication. Presentation should be decided on the reader's end, with the message only containing semantic meaning; HTML allows this.

An XML DTD will eventually replace them, and then unified configuration might be possible. An adequate XML DTD could be self-describing and the configuration application wouldn't have know what it's configuring.

Nope. XML DTD was found to limiting, so they (w3c) invented Schemas . XML begun as a simple solution to a existing problem (need for structured data standard) has exploded to a myriad of rapidly changing standards... Try to keep yourself on track and you'll tongue will die as the amount of letter X having to be pronouced...

• it is a "real" standard by the w3c
• native?? Come on guys! How native is Java? You need a Virtual Machine to run that code. Doesn't look live a native ability to me.. But if it's so important then go for it and send a mail to the guys at mozilla.org..
• The is no company involoved (like in flash, java and even C! and who runs perl.com??). And Netscape and Micro$oft haven't messed it up yet..
• According to the w3c "SMIL presentations can be written using a simple text-editor".. I don't think I have to tell you: As soon as we have something that can be written using a text-editor we can parse it. Meaning: It's searchable!
• Well, if you know less enough you can create crap using every standard. HTML: It's really hard to find a website that is written with the exact definitions (all attributes quoted, e.g.); JS: pop-up windows!?; JAVA: about half of them actually run on my system..; and so on..

SMIL would probably be a more appropriate replacement for Flash. It's also XML-based, and SMIL 1.0 has been a W3C recommendation for over two years.

the red pen has a point about your HTML.

Just a simple validation check at validator.w3.org shows at least six parsing errors for your original link. Writing invalid HTML and blaming it on Netscape is inexcusable. It takes seconds to run HTML through a parser, and using Netscape as a scapegoat for poor markup shows bad taste.

No offense, but this HTML stinks. You have mixed CSS and HTML style tags, valid under HTML 4 Trans. but not the goal of HTML, and you do not enclose attribute data in quotes. You use tables for formatting, and I don't even see how it's needed!

Saying nothing about your technology, it would look a lot more impressive if you wrote your pages in XHTML Strict and did all formatting through CSS. After all, why should people trust your "advanced" XML when you cannot even master XHTML, the simplest form of XML?

the red pen has a point about your HTML.

Just a simple validation check at validator.w3.org shows at least six parsing errors for your original link. Writing invalid HTML and blaming it on Netscape is inexcusable. It takes seconds to run HTML through a parser, and using Netscape as a scapegoat for poor markup shows bad taste.

No offense, but this HTML stinks. You have mixed CSS and HTML style tags, valid under HTML 4 Trans. but not the goal of HTML, and you do not enclose attribute data in quotes. You use tables for formatting, and I don't even see how it's needed!

Saying nothing about your technology, it would look a lot more impressive if you wrote your pages in XHTML Strict and did all formatting through CSS. After all, why should people trust your "advanced" XML when you cannot even master XHTML, the simplest form of XML?

Perhaps I should explain my reasoning on why a link is like a quote.

If I place a site's URL in my website but do not make the reference a hyperlink then clearly I am only doing what bibliographers have been doing for centuries.

However, when I turn the URL into a hyperlink I am then making the actual content of the URL appear inside my web application. The hyperlink is more than just the ASCII text of the URL, such as one might find in a printed bibliography.

Several posters noted that if a hyperlink is placed inside an HTML frame then the address bar will not change after the user clicks on the link, so the user may not know she is at a different site.

In addition, it is fairly common for users to run the browsers in Full Screen mode, in which case the user will not see any address bar.

Lastly, I would mention that the XLink XML Linking Language can make the distinction between a hyperlink and a quote irrelevant, since web sites will be able to link to specific portions of other HTML pages without the pages needing to contain anchors or other special tags.

Your points about the obligation to quote all values, self-closing BR tags, disapearing B and I tags ... have all been carefully considered by W3C when they decided to formalize these things.

Advantages of formalism in markup languages:

1. No need to guess where a value ends, just parse and look for the quotation marks within a tag.

2. No need to check for UPPER and lower case versions of the same tags and attributes; everything is in lowercase.

3. Removal of presentation control allows the same source document to be used for a variety of output devices.

   If you are authoring for any medium or major -sized content provider, chances are that making the content outputable in several of the following formats is a must:

   • HTML
   • WML
   • Postscript (includes PDF)
   • MAN page
   • Newsgroup post

   By using XML as the source format (or, in this case, XHTML Basic), all of these can be covered easily using the appropriate Style Sheet or in a few cases, with sophisticated XSLT schemas.

   • HTML: no transformation needed, already in XHTML; CSS can optionally be used to add visual nicies and presentation control.

   • WML: no transformation needed, unless transport buttons are required. In any case, no presentation control available, so XHTML can pretty much be used as is.

   • Postscript: probably needs an XSLT schema to ensure a predictable, printable layout. Otherwise, the source XHTML document already provides the structure, which can easily be parsed to provide an automated Table of Content page, as a bonus.

   • MAN page: the structure is already provided by XHTML, but must be filtered by troff or similar tools to convert the tagging into appropriate markup for MAN pages; a simple substitution game, easily handled by a script.

   • Newsgroup post: the document structure is already provided by XHTML, but tagging must be stripped and converted to carriage returns, tabs or spaces, to render a plain text message.

For the record, I also hated the disappearance of favorite tags and the requirement of using lowercase for everything, because I still prefer to hand-type my HTML (with the help of auto-expanders that provide tags out of a few keystrokes).

Ever since I adopted HTML Tidy, the conversion to XHTML has been rather painless. Sure, reading lowercase-only tagging took a few weeks to get used to, but nowadays I hardly notice the difference; the tags have become easy to spot, once again.

In closing, I would like to thank W3C people for their efforts, in both web standardization and providing freeware tools to implement these standards. Tidy is something I can no longer live without! ;-)

However, (and this also goes for a lot of other standards out there, such as NTP), you people really need to learn how to distill all those technicalities into more accessible documents: XHTML Basic was the very first human-readable recommendation you produced! Heck, for once, I could find a list of supported tags in one single section, instead of having to decipher an impossibly long DTD!

Your points about the obligation to quote all values, self-closing BR tags, disapearing B and I tags ... have all been carefully considered by W3C when they decided to formalize these things.

Advantages of formalism in markup languages:

1. No need to guess where a value ends, just parse and look for the quotation marks within a tag.

2. No need to check for UPPER and lower case versions of the same tags and attributes; everything is in lowercase.

3. Removal of presentation control allows the same source document to be used for a variety of output devices.

   If you are authoring for any medium or major -sized content provider, chances are that making the content outputable in several of the following formats is a must:

   • HTML
   • WML
   • Postscript (includes PDF)
   • MAN page
   • Newsgroup post

   By using XML as the source format (or, in this case, XHTML Basic), all of these can be covered easily using the appropriate Style Sheet or in a few cases, with sophisticated XSLT schemas.

   • HTML: no transformation needed, already in XHTML; CSS can optionally be used to add visual nicies and presentation control.

   • WML: no transformation needed, unless transport buttons are required. In any case, no presentation control available, so XHTML can pretty much be used as is.

   • Postscript: probably needs an XSLT schema to ensure a predictable, printable layout. Otherwise, the source XHTML document already provides the structure, which can easily be parsed to provide an automated Table of Content page, as a bonus.

   • MAN page: the structure is already provided by XHTML, but must be filtered by troff or similar tools to convert the tagging into appropriate markup for MAN pages; a simple substitution game, easily handled by a script.

   • Newsgroup post: the document structure is already provided by XHTML, but tagging must be stripped and converted to carriage returns, tabs or spaces, to render a plain text message.

For the record, I also hated the disappearance of favorite tags and the requirement of using lowercase for everything, because I still prefer to hand-type my HTML (with the help of auto-expanders that provide tags out of a few keystrokes).

Ever since I adopted HTML Tidy, the conversion to XHTML has been rather painless. Sure, reading lowercase-only tagging took a few weeks to get used to, but nowadays I hardly notice the difference; the tags have become easy to spot, once again.

In closing, I would like to thank W3C people for their efforts, in both web standardization and providing freeware tools to implement these standards. Tidy is something I can no longer live without! ;-)

However, (and this also goes for a lot of other standards out there, such as NTP), you people really need to learn how to distill all those technicalities into more accessible documents: XHTML Basic was the very first human-readable recommendation you produced! Heck, for once, I could find a list of supported tags in one single section, instead of having to decipher an impossibly long DTD!

http://validator.w3.org/check?uri=http%3A%2F%2Fgo. to%2Fmusiclight

Being committed to open standards, I've been spending a lot of time on the W3C site, and when this announcement came out, I followed my curiousity to find out what XHTML is... only to find out that XHTML tags are case sensitive! This is a Bad Thing<tm> IMNSHO, because it breaks too many established conventions for no good reason. Maybe it's because I've used terminals that didn't support lower-case letters, back in the Bad Old Days.

The other major difference between HTML 4 and XHTML 1.0 seems to be that every element must explicitly closed, either with a corresponding closing tag, or the self-closing variety: <br /&gt&Note the space before the closing slash, which older UAs will interpret as an unknown attribute, and therefore ignore, but XML UAs will correctly see as the self-closed element syntax. This is a Good Thing, because it becomes possible to parse a document without any knowledge of which elements require closing tags.

And that is important because the whole point of XML is that it is eXtensible: New tags can be defined and implemented without those annoying

You don't have

• Infernal Exploder Version X.YZ or better,
• SchlockRave Plugin "Foobar for Morons",
• Mutant JavaScript From Hell enabled,

so you suck. Don't come back here until you do, Luzer!

Installation Complete. Windows will now restart your computer.

Honnestly, look at W3C's own homepage and see for yourself what clean HTML means. Already since the first XHTML draft was released almost a year ago, they have simplified their presentation, but the important stuff is still there: the documentation about WEB Publishing standards.

Sure, there are colors and neat formatting tricks, but most of that is done using CSS. Oh, there are a few icons and logos, too. Is the absence of frames and nested tables an obstacle to the content's diffusion? Well, admit it, it is not. All we need to find from W3C is there: the standards.

Also, while the obvious intention of XHTML Basic is to reconcile WML and HTML into a unified common base, note that Web Content created using this barebone standard with linked CSS sheets (as opposed to embeded style rules within the text) also has another strong advantage: it obsoletes the very concept of forcing people to "upgrade" to whatever latest version of a specific browser, which increases accessibility of the content and makes it possible to use "deprecated" browsers without loosing anything significant.

My own appreciation of XHTML Basic, from an HTML comparision point of view, is that it is about half-way between HTML 2.0 and 3.2: basic text and images, plus forms and tables, with XML rigor as a bonus. If your Web Authoring really is about content, not Flash animations demo, then XHTML Basic is all you really need.

XHTML 1.0 is the current W3C recommendation for regular web content (ie the stuff we use HTML for now). XHTML Basic is basically a subset of the XHTML 1.0 functionality and is "designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes".

Basically, XHTML Basic has about the same feature set as HTML 3.2: images, forms, simple tables, etc.

XHTML 1.0 is the current W3C recommendation for regular web content (ie the stuff we use HTML for now). XHTML Basic is basically a subset of the XHTML 1.0 functionality and is "designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes".

Basically, XHTML Basic has about the same feature set as HTML 3.2: images, forms, simple tables, etc.

Note that XHTML Basic is a stripped-down version of XHTML for phones, etc. It's meant to be the future of WML, not the future of Netscape (uh, IE, Opera, whatever).

As for tables, XHTML Basic includes tables, but simplified ones as necessary for reduced screen real-estate devices, not tables as are used to layout complex graphic designs in HTML.

Give XHTML a try -- as far as web authors go, it's pretty much just using lowercase tags and closing them all. Or try HTML Tidy with the "-clean -asxml" options to convert your HTML pretty effortlessly to XHTML. Current browsers will work fine with it.

Disclaimer: I am a member of the XML Forms committee, a descendent of XHTML, but I had nothing to do with XHTML Basic.

Note that XHTML Basic is a stripped-down version of XHTML for phones, etc. It's meant to be the future of WML, not the future of Netscape (uh, IE, Opera, whatever).

As for tables, XHTML Basic includes tables, but simplified ones as necessary for reduced screen real-estate devices, not tables as are used to layout complex graphic designs in HTML.

Give XHTML a try -- as far as web authors go, it's pretty much just using lowercase tags and closing them all. Or try HTML Tidy with the "-clean -asxml" options to convert your HTML pretty effortlessly to XHTML. Current browsers will work fine with it.

Disclaimer: I am a member of the XML Forms committee, a descendent of XHTML, but I had nothing to do with XHTML Basic.

Given that you're posting around here, I'm guessing you have a Linux box handy. Here are some of my favorite sysadmin tools:

• dig - This is a more advanced tool for seeing what's going on with DNS.
• nmap - A great tool for probing your server to make sure you haven't left anything open.
• Apache Bench (ab) - This simple but effective benchmarking tool comes with the Apache server. It's great to see how your site will perform under load.
• wget - a tool for remotely getting web pages; it's very versatile -- you can even use to save a copy of your whole site, just in case.
• Ethereal - Having trouble figuring out what's going on between the browser and your server? This will capture all the packets and decode them into a nice conversation for you.
• vmstat - want to know why your server is slow? Get used to watching the vmstat numbers while it's fast, so you can see what's different when it's slow. It's raw numbers that are hard to interpret, but it's worth getting to know. Maybe this should be another Ask Slashdot question?
• Netsaint - this is my favorite automatic monitoring package. Once your site is in production, you can set this up to patrol things and make sure everything is working. That lets you get on with other stuff, knowing you'll hear about trouble pronto.
• MRTG - A tool that makes excellent long-term graphs of bandwidth use.
• IPtraf - Where MRTG gives you the broad overview, this gives you the second-by-second nitty gritty.
• perl - Last but most is Perl, a Swiss Army chainsaw of languages. If you'll be doing any web stuff, pick up a copy of Learning Perl and spend a little time with it. Once you learn the magic of regular expressions, you will never again say "that's impossible!" to a problem.

As far as non-sysadmin stuff goes, here are some of my other favorites:

• Bugzilla - this is a free and flexible bug tracking system. Highly recommended, especially for those people who don't think they need a bug tracking system. Our designers thought it was silly to start, but even they use it all the time now.
• CVS - Like bug tracking, most web sites don't think they need version control. Most web sites are wrong! CVSweb is also recommended.
• HTML Tidy - bad HTML in, good HTML out.
• WebTV Simulator - Sure, you and I don't use WebTVs, but a lot of people do. Browse your site with this to see how the other half surfs.
• VMWare - Along similar lines, VMWare is a Windows box emulator. I use it to keep a bunch of synthetic windows machines with a variety of OS versions and browser versions. It makes QA much easier.

And if there are particular tasks that have you stumped, come back and ask again. 'Round these parts, we have big toolboxes.

the upcoming battle between XML standards proposed by Sun and Microsoft.

Golly. To think, all this time I was under the impression that XML was the standard created by the W3C. But hey, if Microsoft says we need an XML standard, I guess we do.

I wonder what they're going to call it... "Microsoft XML: The standard standard."
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"

I thought XML already had a standard definition.

It does.

There are a few rules, and you include a DTD to interpret any particular implementation of XML.

No, not quite. The DTD basically just says what the valid tags are for a certain XML dialect. To actually "understand" the information requires an application to parse the XML file, or use a component that does this.

The company I'm presently working at has been using a specific implementation of XML for communication between servers, and they owe nothing to MSFT or Sun because of it. What exactly have these two companies done?

They were partially responsible for developing the XML standard. They supply free parsers for you to use in your own projects. They implement XML support in their products.

I find the article vague at best. Have they provided XML interpreters?

As far as I can tell, they have both implemented a way for businesses to communicate in certain ways, using the XML standard. These ways are incompatible with each other, so presumably, applications will have to have different code to support each standard. I suppose it's like the way a web browser is expected to support both GIF and PNG images - the formats do the same job, but do it in different ways.

accessibility is a good idea, since i have heard things about agencies getting sued for not being ADA compliant. As far as content goes, I would advise you to look into XML/XSLT for seperating your content and presentation. You can effectively build an information architecture using XML, and you can style it with XSLT. This is useful if you have multiple views of your data (snazzy dhtml/html based, Handheld based, PDF, ADA compliant [i.e. no frames with an shitload of alt tags]). As far as layout and design goes, i suggest you consult works by Jacob Niesen. He is a little overated (and overpaid) in my opinion, but he has decent ideas now and again. Good luck

accessibility is a good idea, since i have heard things about agencies getting sued for not being ADA compliant. As far as content goes, I would advise you to look into XML/XSLT for seperating your content and presentation. You can effectively build an information architecture using XML, and you can style it with XSLT. This is useful if you have multiple views of your data (snazzy dhtml/html based, Handheld based, PDF, ADA compliant [i.e. no frames with an shitload of alt tags]). As far as layout and design goes, i suggest you consult works by Jacob Niesen. He is a little overated (and overpaid) in my opinion, but he has decent ideas now and again. Good luck

accessibility is a good idea, since i have heard things about agencies getting sued for not being ADA compliant. As far as content goes, I would advise you to look into XML/XSLT for seperating your content and presentation. You can effectively build an information architecture using XML, and you can style it with XSLT. This is useful if you have multiple views of your data (snazzy dhtml/html based, Handheld based, PDF, ADA compliant [i.e. no frames with an shitload of alt tags]). As far as layout and design goes, i suggest you consult works by Jacob Niesen. He is a little overated (and overpaid) in my opinion, but he has decent ideas now and again. Good luck

NY State has mandated (see its Technology Policy 9903) that all state agency web sites must conform to the W3C Web Content Accessibility Guidelines. Of course, I don't know of any specific sites that have been brought into conformity yet, and NY State hasn't to my knowledge made any extra resources available to do this, but it remains an important goal despite the bureaucrats who hot-potatoed it.

Lots of specifics have been posted by others here. The W3C guidelines are at http://www.w3.org/TR/WAI-WEBCONTENT/ and the state policy is listed at http://www.irm.state.ny.us/policy/99-3.htm.

Please post back after you've come up with a plan, lots of us would be interested.

Dave

In particular, the KISS principle applies to Web design: the simpler a site design is, the more likely it is to work well on a wide range of devices. This doesn't mean it needs to be ugly -- careful use of stylesheets can produce an elegant, colourful, well laid out design from very simple markup.

Most important is to follow the Web Accessibility Initiative guidelines.

However, on one point I'd like to disagree strongly with what's been posted above: I really don't like the use of PDF. It's an exceedingly inflexible format -- after all, inflexibility is precisely what it's designed for. It is most unlikely to be widely accessible on the range of access devices people use and will use. PDF is for people who grew up in the era of flattened dead trees and simply cannot adjust to a world in which text can be presented to meet the needs of the user.

Stick to HTML: the simpler, the better.

Don't get me wrong, I do like the site, but they make a lot of the fact that they follow all known standards, but a quick look at http://validator.w3.org/check?uri=http://www.open. gov.uk shows that their front page throws up 10 errors - all because they have not even checked it against a validator. Had they checked it, they would have realised that they have neglected to put an explanation mark in their DOCTYPE declaration at the top of the page (they have used <DOCTYPE ... instead of <!DOCTYPE ...). It is a basic error, and one which certainly should have been noticed during their testing stage.

Paul.

http://www.w3.org/WAI/

BTW, I always use the printer-friendly version (if there is one) for ordinary Web browsing.

The BBC's website has a CGI script Betsie which automatically generates an 'accessible' version of a web page. But this is not an ideal solution, it would be better to write the page in an accessible way to start with. HTML-linters like Bobby, Weblint, and Tidy, not to mention just validating properly with nsgmls, can help here. Also read the W3C's accessibility guidelines.

But I don't mean to rant too much on the web purist's favourite topic of alt tags and not using tables for layout. I mean, it's not as if I even use Lynx for browsing. One thing I would like to have is a clear sense of real people behind the site. This means having a contact address (or at least a link to a contact page) on every page, and where appropriate, other meta-data like which department is responsible for this page, where the information comes from, when it was last updated, and so on.

Also try to make your URLs last a reasonably long time (i.e. not like microsoft.com, for anyone familiar with that site). This means that people can bookmark a site containing useful information and go back to the same page later. It also helps search engines.

Finally, it might be a good idea to support SSL connections and get a certificate, possibly signed by the government itself. That way people can feel reassured that 'the bad guys' aren't getting in the way.

BTW, I always use the printer-friendly version (if there is one) for ordinary Web browsing.

The BBC's website has a CGI script Betsie which automatically generates an 'accessible' version of a web page. But this is not an ideal solution, it would be better to write the page in an accessible way to start with. HTML-linters like Bobby, Weblint, and Tidy, not to mention just validating properly with nsgmls, can help here. Also read the W3C's accessibility guidelines.

But I don't mean to rant too much on the web purist's favourite topic of alt tags and not using tables for layout. I mean, it's not as if I even use Lynx for browsing. One thing I would like to have is a clear sense of real people behind the site. This means having a contact address (or at least a link to a contact page) on every page, and where appropriate, other meta-data like which department is responsible for this page, where the information comes from, when it was last updated, and so on.

Also try to make your URLs last a reasonably long time (i.e. not like microsoft.com, for anyone familiar with that site). This means that people can bookmark a site containing useful information and go back to the same page later. It also helps search engines.

Finally, it might be a good idea to support SSL connections and get a certificate, possibly signed by the government itself. That way people can feel reassured that 'the bad guys' aren't getting in the way.

"As a government agency what standards are you required to meet with your web site?"

Although it pains me to say it, if that is true that would mean that, for once, government is setting a good example of what to do.

--
J, Internetist

1. Be sure to get it indexed on all the major search engines and directories
2. Include a local search feature (even if it is only Google's site search feature)
3. Include contact information
4. Meta tags to enable easier finding of info.
5. Accessability!

1. Shockwave, Java, IE/Netscape tags, (excessive) javascript (all sections should worth with or without it)
2. Don't make any page more than ~4 clicks from the main page.
3. Here are some (karma whoring) tips from Tim Berners-Lee and Friends
4. Don't link to goatse.cx

1. Be sure to get it indexed on all the major search engines and directories
2. Include a local search feature (even if it is only Google's site search feature)
3. Include contact information
4. Meta tags to enable easier finding of info.
5. Accessability!

1. Shockwave, Java, IE/Netscape tags, (excessive) javascript (all sections should worth with or without it)
2. Don't make any page more than ~4 clicks from the main page.
3. Here are some (karma whoring) tips from Tim Berners-Lee and Friends
4. Don't link to goatse.cx

This has been around for years now. PICS not only provides a rating scheme (such as RSAC or SafeSurf), but it allows anyone (including the site's own publishers) to invent their own rating schemes and allow users to install them in PICS capable browsers. If you want a rating scheme that excludes Evolutionary Science and favours Creationism, then you're quite at liberty to use one.

The same rating scheme can even be applied to sites publishing their metadata to search engines. It's practical, useful and an interesting development area to use this technology to state, "I'm a member of the Good Museums Guild, and when I say this page shows pictures of pandas and is especially suitable for children, then you can trust me."

Insightful ? Get a clue, moderators....

Damn, this sucks. I like Opera..

There are a lot of things in IE that aren't reflected in the standards, however. Damn useful things, too, more's the pity.

Oh, well. Thanks.

--

Ever heard of XHTML? (specification)

It has the potential to be all that, AFAIR. I read the specification a while ago and it looked mighty interesting. Newly standardised and easy to code, especially if you are familiar with the concepts of XML.

Trian

Ever heard of XHTML? (specification)

It has the potential to be all that, AFAIR. I read the specification a while ago and it looked mighty interesting. Newly standardised and easy to code, especially if you are familiar with the concepts of XML.

Trian

I agree that XML does what you describe, but if you re-read the part you quoted, he actually does NOT say exactly that XML handles 'content and visual formatting', merely that it promises to clean up that boundary. This sounds like "let XML define the data, and let <technology X> define the visual formatting" to me, but it is a blatant misunderstanding that XML is an alternative to HTML as stated in the last sentence.

I've been doing numerous web projects where we use XML for data, and use some form of transformation to HTML for browser presentation. Look into XSLT for what I think is the coolest way to make these transformations. When done correctly, XSLT is orders of magnitudes faster than some ASP/PHP page combined with client-side scripting will ever be, IMNSHO.

The Apache XML project has FOP, which translates XSL:FO to PDF.

However, I don't see this happening. The reason for that is inertia. People like HTML. People know HTML. Web browsers support it. People hate change.


Luckily for people, HTML is already being replaced by XHTML+XML+XSLT+ECMA Script, a combination that LaTeX cannot compete with on merit.

An accurate translation of the topic's question would be:

Could LaTeX replace XHTML+XML+XSLT+ECMA, already partially supported in browsers with full support to follow sooner rather than later?

Long answer: In a world of infinite possibilities, I suppose there's a small but non zero chance that it could. Short answer: NO.

It's nice that the questioner learned LaTeX but, no offense, it would be nicer if he also spent some time reading and thinking about the content on http://www.w3.org/. I mean, the question was about the www, right?

LaTeX is a wonderful way of expressing mathematical notions and is the defacto standard amoung mathematicians. Once you know TeX, using something else is a real downer, from the elegance, portability and functionality standpoints.

Unfortunately for the more mathematical amoung us, LaTeX will never/has not caught on as a competitor to HTML, largely because so little of the web needs precise mathematical notation.

A few years ago, in the Notices of the American Mathematical Society, an article appeared about the promise of MathML. All the research mathematicians I know had the same reaction to the article, which was: "It took 40 lines of code to express x^2+4x=0? Is this some kind of joke?" (see the article in PDF, which was rosy about MathML and seemed to think that 40 lines of code was reasonable for that...) Mozilla supports MathML but MathML has not caught on with mathematicians and will not budge anyone away from TeX. People post their preprints in TeX, journals and conferences want articles in TeX, and it is the most reasonable way of exchanging mathematical papers.

It would be nice if TeX were more widely used, but its role is different than HTML. TeX is optimized for typesetting documents that have significant mathematical structure and though it can take a while to render something complicated in TeX, the page layout will be gorgeous. HTML or its replacements need to be quickly rendered by the browser and only very rarely have the need to use mathematical expressions.

LaTeX is an excellent tool, but it's a tool to organize information into platform-independent documents. These documents are set up using pre-defined types (this is an article, a book, etc.), and then organized following the established structure for that document type. LaTeX then provides a variety of tools to simplify cross-referencing, indexing, and otherwise making logincal use of that information.

Using LaTeX to provide greater control over the layout of information on the Web seems like it would be falling into the same trap that ate HTML -- if you remember, HTML was originally intended to organize information in a logical hierarchy, not make pretty pictures.

The paragraph of links:
At least one other person has already pointed to TeX 2 HTML and LaTeX 2 HTML, so I'll just add that if you're interested in well structured documents on the Web, it is actually true that XML has a lot to offer. And as long as I'm listing sites off like a madman, let's not forget the good old W3C.

Oh, yeah...http://www.latex-project.org...


Coke Is It (1982)

So here's my proposal: Let's get all of the major and some of the minor browsers companies together and (by some miracle) get them all to agree on standards or something. Then make THEM be the consortium that creates the standards.

Okay, so you'd like to replace the W3C with... the W3C.

You can read more about your new consortium at the W3C Web site. The W3C member list includes all major browser makers and many minor ones, as well as about 375 other organizations.

So here's my proposal: Let's get all of the major and some of the minor browsers companies together and (by some miracle) get them all to agree on standards or something. Then make THEM be the consortium that creates the standards.

Okay, so you'd like to replace the W3C with... the W3C.

You can read more about your new consortium at the W3C Web site. The W3C member list includes all major browser makers and many minor ones, as well as about 375 other organizations.

Get Amaya. Stop worrying about which broken code you're going to support and do it right from the beginning.

Woohoo! Yet another webmonkey who thinks that HTML is programming. Sure, it's worthwhile, but you get nowhere trying to impress the geek crowd by calling it development.

Here is the intro:

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense."

There's a chapter or two written by Charles Allen about WIDL in the XML Handbook (Goldfarb, et al).

But it's a technology that is dated now -- webMethods has moved on to B2B, and anyone who is jumping up and down about screen scraping in 2000 is just a little bit behind the times.

--brian

http://xml/linux/newbie

transferProtocol://contentType/highLevelCategory/l owerLevelCategory

Hm, no. For one thing, a document could, and often should, exist in many different content types, and servers should use content negotation to serve them.

More importantly, you impose a hierarchal structure on the web, but the web was invented to solve the many problems hierarchal systems represent.

Now, the DNS does represent a problem for the web, TimBL discuss this in his book, but you're going in the wrong direction, IMHO.

if you haven't looked into RDF and the importance of metadata on the web, there's no time like the present.

it wouldn't hurt to read weaving the web, by tim berners-lee, the inventor of the world-wide web, either. he has chapter 1 online.

if you haven't looked into RDF and the importance of metadata on the web, there's no time like the present.

it wouldn't hurt to read weaving the web, by tim berners-lee, the inventor of the world-wide web, either. he has chapter 1 online.

if you haven't looked into RDF and the importance of metadata on the web, there's no time like the present.

it wouldn't hurt to read weaving the web, by tim berners-lee, the inventor of the world-wide web, either. he has chapter 1 online.

The Semantic Web Page is a good starting point.
TBLs personal notes Is another one. Probably the best one, actually.

"The Semantic Web" was a term coined by Tim Berners-Lee (we all know who that is, don't we?) to describe a www-like global knowledge base, which when combined with some simple logic forms a really interesting KR system. His thesis is that early hypertext systems died of too much structure limiting scalability, and current KR systems (like CYC) have largely failed for similar reasons. The Semantic Web is an attempt to do KR in a web-like way.

This really could be the next major leap in the evolution of the web. Do yourself a favour and check it out. And it's not based on hacks for screen-scraping HTML, it's based on real KR infrastructure.