Slashdot Mirror

I don't think the evidence on RDF mailing list supports that opinion. Look at the literature in the bookstores about semantic web. If anything, it is full of confusion and the specification is poorly written compared to the HTML and XML specification.

Triplet does not equal (Subject verb object). What the RDF spec describes is closer to Natural Language parsing concepts. There are many similarities between what the RDF describes as RDF Model graph and dependency grammar techniques http://w3.msi.vxu.se/~nivre/research/sdg.html.

The fact is RDF is really just triplet. Not surprising that it can be represented in N3 (where 3 stands for triplet). Take a look at this example taken from wikipedia :

http://en.wikipedia.org/Tony_Benn> http://purl.org/dc/elements/1.1/title> "Tony Benn" . http://en.wikipedia.org/Tony_Benn> http://purl.org/dc/elements/1.1/publisher> "Wikipedia" .

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax -ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf :Description rdf:about="http://en.wikipedia.org/Tony_Benn">
<dc:title>Tony Benn</dc:title>
<dc:publisher>Wikipedia</dc:publisher>
</rdf:Desc ription>
</rdf:RDF>

So take another look at RDF, you'll be surprised.

I don't think the evidence on RDF mailing list supports that opinion. Look at the literature in the bookstores about semantic web. If anything, it is full of confusion and the specification is poorly written compared to the HTML and XML specification.

Triplet does not equal (Subject verb object). What the RDF spec describes is closer to Natural Language parsing concepts. There are many similarities between what the RDF describes as RDF Model graph and dependency grammar techniques http://w3.msi.vxu.se/~nivre/research/sdg.html.

The fact is RDF is really just triplet. Not surprising that it can be represented in N3 (where 3 stands for triplet). Take a look at this example taken from wikipedia :

http://en.wikipedia.org/Tony_Benn> http://purl.org/dc/elements/1.1/title> "Tony Benn" . http://en.wikipedia.org/Tony_Benn> http://purl.org/dc/elements/1.1/publisher> "Wikipedia" .

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax -ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf :Description rdf:about="http://en.wikipedia.org/Tony_Benn">
<dc:title>Tony Benn</dc:title>
<dc:publisher>Wikipedia</dc:publisher>
</rdf:Desc ription>
</rdf:RDF>

So take another look at RDF, you'll be surprised.

In short, the goal of the semantic web is to make the web (semantic) understandable to computers (by any mean possible). This, to bring new possibilities and automatism. For this to be possible, we need to explicit things in a formal manner.

That second link goes to http://www.google.com/url?sa=U&start=1&q=http://ww w.w3.org/2001/sw/&e=9707
How is that different to linking to http://www.w3.org/2001/sw/?

Is Slashdot trying to improve someone Google ranking?

(Also, did Slashdot always linkify URLs entered as plaintext? I didn't write any "a href" for those two.)

Firefox, though built from the ashes of Netscape, was mainly driven as an alternative to I.E. -- it just had new and innovative features added along the way. But that's no different from the "embrace and extend" that we give MS so much hassle for.

the fun thing is that it seems to have been generated with MS Word, and simply saved as HTML (take a look at the source). The feds (if they did that design) could at least have had the decency to use less screwed up HTML...

anybody care to explain what the "RTJKJAS" at the very end are supposed to mean?

A ajax is based off of XMLHttpRequest which is not standardized, firefox cloned Microsoft's ActiveX XMLHttpRequest object. XMLHttpRequest will eventually make it into the DOM, well hopefully. There's been discussion on the mailing list about it.

oops...typo: that's W3C.

WOW, that was a lot of URLs!

Yeah, but that's what we have the W3C for.

Why don't you actually check with the specification before attempting to correct me?

The Strict DTD defines BODY like this:

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->

The Transitional DTD defines BODY like this:

<!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body -->

The former permits only block level elements as children of BODY where the latter is more lax.

Why don't you actually check with the specification before attempting to correct me?

The Strict DTD defines BODY like this:

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->

The Transitional DTD defines BODY like this:

<!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body -->

The former permits only block level elements as children of BODY where the latter is more lax.

Years ago, at a W3C conference, I nearly got into a fistfight with the Amaya folks (they swung first!). I was the senior engineer on a GUI HTML editor project and they wanted to know why I didn't test the output on Amaya. I told them it's because "Amaya doesn't matter." That's when they started swinging....

Other open source browsers:

• Amaya - from W3
• Links - my current text browser of choice
• W3M - another text browser

For one, I AM in XHTML 1.1 spec.

No, you aren't.

What I am seeing right now is: dave-dodds.com is labelled as XHTML 1.0 Transitional. It includes an XML prolog. It is being transmitted as text/html.

These three things are mutually exclusive if you want to stay in spec. Go and read the RFC I pointed you to.

Check the W3C Conformance guidelines for XHTML 1.1.

Why? You aren't using XHTML 1.1, and even if you were, you can't transmit it as text/html.

If you want to hear it from the horse's mouth, read XHTML Media Types.

Last time I checked W3C was in charge of standards.

Again, you are wrong. The W3C is a vendor consortium, not a standards body. That's why they publish recommendations. Organisations like ISO and ECMA publish standards. In fact, ISO have published ISO-HTML.

Right, so everyone should write sloppy unstandardized code that gets dislayed incorrectly or not at all on mobile browsers and/or takes forever to load?

What a load of bullshit. How in hell can you misinterpret me pointing out that you write non-standard code as an attempt to advocate writing non-standard code? I write standard code. You do not.

Quite frankly, I'm amazed at just how spectacularly you can get things wrong. How about you start reading and understanding the specifications before talking about them? The RFC I pointed you to is a good start.

XHTML does not force you to stop using the FONT element (please do not call it a tag). FONT is still available in XHTML 1.0 Transitional.

Let me repeat this once again: XHTML 1.0 Transitional has exactly the same elements as HTML 4.01 Transitional. XHTML 1.0 Strict has exactly the same elements as HTML 4.01 Strict.

Why is it that whenever a topic like this comes up, somebody who is out of spec. posts a comment telling everybody they are in spec?

For one, I AM in XHTML 1.1 spec. and because it can be considered Insightful.

RFC 2854 allows you to transmit XHTML 1.0 documents that follow the compatibility profile described by the XHTML 1.0 specification (Appendix C).
Your pages don't follow that compatibility profile because you include the XML prolog (the

Hmmm... seems you are confused. Check the W3C Conformance guidelines for XHTML 1.1. (http://www.w3.org/TR/xhtml11/conformance.html)
It clearly states:
Note that in this example, the XML declaration is included. An XML declaration like the one above is not required in all XML documents. XHTML document authors are strongly encouraged to use XML declarations in all their documents.
Last time I checked W3C was in charge of standards.

The fact that you are concerned with mobile browsers is amusing, since this mistake actually trips up a couple of mobile browsers (Pocket IE is one, IIRC).

Amusing huh? Right, so everyone should write sloppy unstandardized code that gets dislayed incorrectly or not at all on mobile browsers and/or takes forever to load? Great idea, while I'm at it, I'll stop designing for everyone who isn't running Windows XP and IE 6.0. I mean those users don't care about rendering performance anyhow, right? As for pocket IE, it appears that bug has been fixed. http://blogs.msdn.com/windowsmobile/archive/2004/0 8/12/213692.aspx

Pre-excuse: I'm not entirely sober right now...

HTML 3? - 330 errors. Nearly as bad as /. ;)

Personally I will be glad when dinosaurs like yourself finally become extinct - sure i'm just some young 'whippersnapper' compared to you, i've only been doing website development since 1998 but I have adopted my practices as the nature of the web has changed, both for the benefit of low-bandwidth users, disabled users and such as well as for myself. Doing all styling with a CSS file makes my life an order of mangitude easier when I have to go back to a previous site and do a redesign. Semantic, non-presentation markup saves significantly on bandwidth used and when combined with caching of stylesheets the bandwidth saving can be fairly significant on more popular sites. The lack of junk markup means my sites have a significantly higher content to markup ratio than they once did (and competitors still do) and there is significant evidence that search engines use this as one of their variables for search rankings.

OTOH I still mostly use HTML 4.01 because for most sites there is currently no real reason to use XHTML and probably wont be for some time and I refuse to send XHTML as text/html on my clients sites (although most of my own site is currently XHTML 1.0 valid) because that is not what it is. One must find a sane balance between the almost 'faddish' XHTML & CSS pushing and the realities of modern user agents and for now there is nothing I can do with XHTML (that works in all popular browsers) that I cannot do with HTML 4.01, and HTML 4.01 is alot more supported than XHTML and will be for the forseeable future.

At the moment, there is a non-standard convention supported by most browsers that code like will open a link in a new window.

This is actually a standard supported in, at least, HTML 4.0. It's one of the "Attributes defined elsewhere" on the w3 specs.

The "target" atribute is defined in the frames set.

At the moment, there is a non-standard convention supported by most browsers that code like will open a link in a new window.

This is actually a standard supported in, at least, HTML 4.0. It's one of the "Attributes defined elsewhere" on the w3 specs.

The "target" atribute is defined in the frames set.

If the developers of Netscape Navigator had this fanatical devotion to the W3C that seems to be popular lately, we wouldn't have tables, scripts, or any kind of styles (neither nor CSS). None of that was in the standard (HTML 2.0) at the time.

Bzzt, wrong. Tables were proposed as part of HTML 3.0 which was being worked on at the time. HTML 2.0 already had a way of incorporating stylesheets into documents, and in fact it's the same code that is used today.

Even if that wasn't true, Netscape had nothing to do with the introduction of stylesheets. They were late to the party with JSSSL, when CSS and DSSSL already existed.

If the developers of Netscape Navigator had this fanatical devotion to the W3C that seems to be popular lately, we wouldn't have tables, scripts, or any kind of styles (neither nor CSS). None of that was in the standard (HTML 2.0) at the time.

Bzzt, wrong. Tables were proposed as part of HTML 3.0 which was being worked on at the time. HTML 2.0 already had a way of incorporating stylesheets into documents, and in fact it's the same code that is used today.

Even if that wasn't true, Netscape had nothing to do with the introduction of stylesheets. They were late to the party with JSSSL, when CSS and DSSSL already existed.

http://www.w3.org/Amaya/

Actually, HTML 4.01 already forced you to remove the font tag.

This is not true, the <font> element type is present in HTML 4.01.

What I would like to see is a book that skips all the fluff that we've seen before and goes straight to browser bugs.

Absolutely. There are a million tutorials that will teach you all about CSS in theory, and once you have a reasonable base knowledge you can actually go into the W3C spec itself and dig into the details, but when it comes time to make your pretty new XHTML/CSS2 page work in IE you better have a boatload of knowledge.

After 5 years, and the thankful death of NS4 and IE5 (for the most part), I can debug my XHTML/CSS pages extremely efficient, but good references are still necessary. My two favorites:

CSS-discuss mailing list wiki
&
Position is Everything

It should have a Javascript DOM-based moving or something. Marquees are, like, so IE3.

Better yet, be thoughtful of screen-reader users, and make it a static list that has scrolling abilities.

It should have a Javascript DOM-based moving or something. Marquees are, like, so IE3.

Better yet, be thoughtful of screen-reader users, and make it a static list that has scrolling abilities.

property : IDENT;
ident [-]?{nmstart}{nmchar}*

THERE WAS NO SPECIFICATION back then, or at least not any coherant ones.

This is not true. The HTML specification and the HTML 2.0 specification. Additionally, there was an HTML+ draft. The W3C were working on HTML 3 (draft here) and browser vendors were free to participate.

Remember, HTML 1 and 2 were specifications of the IETF who then summarily dropped it.

This is not true either. HTML 2 was published as an RFC by the IETF, but HTML "1" had nothing to do with the IETF.

HTML 3 was the first spec they issued

Again, incorrect. HTML 3 was never finished. The reason why it wasn't finished was because the W3C considered it more valuable to specify all the proprietary crap that the browser vendors were adding so that it worked consistently across browsers, instead of publishing a well designed specification like HTML 3.

Nobody wanted to implement it.

That's funny. The development process was open to all-comers. If the HTML 3 drafts were so terrible, why didn't the browser vendors suggest changes?

You are talking about the browser vendors as if they were somehow forced to ignore people. When Netscape explained their concept of frames on the mailing lists, they got several responses explaining how the concept was fundamentally flawed, exactly how they could break, and suggestions for fixing them. Netscape ignored everyone and went ahead with their original plans. And lo and behold, we all found out that frames are crap, and even Netscape stopped using them on their own homepage.

THERE WAS NO SPECIFICATION back then, or at least not any coherant ones.

This is not true. The HTML specification and the HTML 2.0 specification. Additionally, there was an HTML+ draft. The W3C were working on HTML 3 (draft here) and browser vendors were free to participate.

Remember, HTML 1 and 2 were specifications of the IETF who then summarily dropped it.

This is not true either. HTML 2 was published as an RFC by the IETF, but HTML "1" had nothing to do with the IETF.

HTML 3 was the first spec they issued

Again, incorrect. HTML 3 was never finished. The reason why it wasn't finished was because the W3C considered it more valuable to specify all the proprietary crap that the browser vendors were adding so that it worked consistently across browsers, instead of publishing a well designed specification like HTML 3.

Nobody wanted to implement it.

That's funny. The development process was open to all-comers. If the HTML 3 drafts were so terrible, why didn't the browser vendors suggest changes?

You are talking about the browser vendors as if they were somehow forced to ignore people. When Netscape explained their concept of frames on the mailing lists, they got several responses explaining how the concept was fundamentally flawed, exactly how they could break, and suggestions for fixing them. Netscape ignored everyone and went ahead with their original plans. And lo and behold, we all found out that frames are crap, and even Netscape stopped using them on their own homepage.

THERE WAS NO SPECIFICATION back then, or at least not any coherant ones.

This is not true. The HTML specification and the HTML 2.0 specification. Additionally, there was an HTML+ draft. The W3C were working on HTML 3 (draft here) and browser vendors were free to participate.

Remember, HTML 1 and 2 were specifications of the IETF who then summarily dropped it.

This is not true either. HTML 2 was published as an RFC by the IETF, but HTML "1" had nothing to do with the IETF.

HTML 3 was the first spec they issued

Again, incorrect. HTML 3 was never finished. The reason why it wasn't finished was because the W3C considered it more valuable to specify all the proprietary crap that the browser vendors were adding so that it worked consistently across browsers, instead of publishing a well designed specification like HTML 3.

Nobody wanted to implement it.

That's funny. The development process was open to all-comers. If the HTML 3 drafts were so terrible, why didn't the browser vendors suggest changes?

You are talking about the browser vendors as if they were somehow forced to ignore people. When Netscape explained their concept of frames on the mailing lists, they got several responses explaining how the concept was fundamentally flawed, exactly how they could break, and suggestions for fixing them. Netscape ignored everyone and went ahead with their original plans. And lo and behold, we all found out that frames are crap, and even Netscape stopped using them on their own homepage.

The nightly builds can be grabbed from ftp.mozilla.org/pub/mozilla.org/ firefox/nightly/latest-trunk/

Some variations on the svg tiger can be found through Google.

...until you have a detailed technical drawing with specifically-located text labels in it.

And you want to zoom in without hitting some blocky aliasing artifacts from a bitmap.

SVG, easily rendered and easily created and edited with free tools is what is required to obsolete PDF.

If you're doing a destructive action based on a GET request, then your application is broken.

I could quote the chapter and verse, but I'll instead assume that you can read, especially the last sentence of section 9.1.1.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.h tml

I think they are mistaken. Link prefetching is a standard, and the webmaster is in charge of deciding which links are prefetched, by adding the appropriate tags to links.

And just how do you propose the server keeps track of people and the information saved on the server? HTTP connections are essentially anonymous for the purposes of a web server. Sure, they have an IP address on the other end, but that could be a proxy or something else. There are two possibilities to accurately tracking sessions. One is to use a cookie to save a session ID of some sort, which is what you usually see nowadays. The other ways is appending a honking great ?PHPSESSION=.... string to the URL. The latter is frowned upon by the W3C and makes URL's difficult to bookmark. So yes, you do need cookies.

Cookies are horrendously abused. There should never be a need for cookies until you choose preferences or login to a website.

It's about time the net at large woke up to P3P, or better yet webmasters started thinking before they mindlessly implement cookies for tracking their visitors.

With the mention of both Third Voice and the Annotation Engine, I'm surprised the somewhat more standard (or at least endorsed by the W3C) Annotea wasn't referenced.

Besides having native support in Amaya, there's a plug-in being actively developed for the Mozilla family of browsers.

With the mention of both Third Voice and the Annotation Engine, I'm surprised the somewhat more standard (or at least endorsed by the W3C) Annotea wasn't referenced.

Besides having native support in Amaya, there's a plug-in being actively developed for the Mozilla family of browsers.

When will we see mainline browser support of this?
http://www.w3.org/AudioVideo/
Some of the demos I have seen are really cool!

You can't even do HTML/CSS properly, what makes you think Google would want you?

Because Google can't do HTML/CSS properly either, maybe? They're quite the match, when it comes to that.

Or, to put it another way, Opera doesn't support SVG - it supports a subset of SVG.

Are you only speaking of incomplete SVG, or actually of SVG Tiny (the first profile of SVG Mobile)? If you're meaning the latter, then it really isn't a subset of SVG, just a different flavor of it. In fact, the SVG working group is moving away from SVG Tiny being a 'subset' of SVG Full. Instead they're are moving to having SVG Tiny be the base language and SVG Full to be "extensions to [it], forming a superset". So, as long as an implementation supports SVG Tiny, it seems completely fair to say it "supports SVG." (And in that case it's also very different than MSIE and CSS)

Or, to put it another way, Opera doesn't support SVG - it supports a subset of SVG.

Are you only speaking of incomplete SVG, or actually of SVG Tiny (the first profile of SVG Mobile)? If you're meaning the latter, then it really isn't a subset of SVG, just a different flavor of it. In fact, the SVG working group is moving away from SVG Tiny being a 'subset' of SVG Full. Instead they're are moving to having SVG Tiny be the base language and SVG Full to be "extensions to [it], forming a superset". So, as long as an implementation supports SVG Tiny, it seems completely fair to say it "supports SVG." (And in that case it's also very different than MSIE and CSS)

I agree, but remember -- SVG is a web standard. It can replace Macromedia Flash, which is proprietary.

Please read the standard. It's all perfectly legitimate under XML.

It is indeed an official standard.

Usefully, with the <object> tag, you can specify alternative objects to render. So you can provide a SVG, and a PNG to render instead, then a GIF to render instead, then a plaintext alternative.

Right, but think about this - the vector graphic describes lines. However, that does not equate to "infinite resolution".

Ahh... but that's where things like the <switch> element, CSS, and the new <multiImage> support coming in 1.2

Right, but think about this - the vector graphic describes lines. However, that does not equate to "infinite resolution".

Ahh... but that's where things like the <switch> element, CSS, and the new <multiImage> support coming in 1.2

However, what does happen is that you may not have enough "lines" to display well at a larger resolution. What looked good with 200 lines at a small resolution may look like total crap at a high resolution.

From Appendix A: SVG Requirements

[...] Paths can be made up of any combination of the following:

• Straight line segments
• Cubic bezier curved segments
• Quadratic bezier curved segments
• Elliptical and circular arcs
• No other curve types (Other curve types such as splines or nurbs are either technically very difficult, industry-specific and/or have not established themselves as industry standards as much as beziers.)