Slashdot Mirror

Well that would probably be a bug in IE4 since, according to the W3C, that page is perfect XHTML.

Oh, but it is! As the msn.com site does not pass validation, it can be treated any way the browser chooses.

Plain wrong. RFC2068 section 10.2.7.

javascript:( function(){
var z,i,e,s;
z = document.getElementsByTagName('LINK');
for (i = 0; i < z.length; ++i) {
if (z[i].rel.toLowerCase().indexOf('next') != -1){
document.location=z[i].href;
return;
}
};
z = document.links;
for (i = 0; i < z.length; ++i) {
if ((z[i].innerHTML && z[i].innerHTML.toLowerCase().indexOf('next') != -1)){
document.location=z[i].href;
return;
}
}
IB=1;
function isDigit(c) {
return ("0" <= c && c <= "9")
}
L = location.href;
LL = L.length;
for (e=LL-1; e>=0; --e)
if (isDigit(L.charAt(e))) {
for(s=e-1; s>=0; --s)
if (!isDigit(L.charAt(s)))
break;
break;
}
++s;
if (e<0) return;
oldNum = L.substring(s,e+1);
newNum = "" + (parseInt(oldNum,10) + IB);
while (newNum.length < oldNum.length)
newNum = "0" + newNum; location.href = L.substring(0,s) + newNum + L.slice(e+1);
})();

You need support for the LINK tag, which has been in HTML forever, but doesn't have much mainstream browser support. (Mozilla had something, but it broke and nobody fixed it, AFAICT.)

This supports such concepts of "Next", "Prev", and "Up" (index).

Most classic document mgmt systems support these ideas, but for some reason every one gets by on the Internet with Back and Forward.

Another nice change is that stylesheet change on Dave Hyatt's weblog [mozillazine.org] actually works now.

But there's still no GUI for choosing a stylesheet, though (which is why Dave Hyatt has to have JavaScript for it). A user-accessible method for choosing which stylesheet to display isrequired by the CSS 2 spec. (section 3.2, point 5)

Give me a View->Use Style menu like Mozilla!!

As far as styling XML goes, your XML apparently does have to have the DOCTYPE stuff set up correctly. This means you get no joy with the stuff on the w3c Styling XML site; safari won't display the xml files there at all.

Oh yeah: it's a bit faster...not that you're likely to notice.

Well, there is an "obviousness" exception, related to prior art. Shouldn't that take out most of this? People have been doing keyword searches since the invention of the index, for example.

The nonobvious exception is of course nonobvious in appplication. And the USPTO doesn't always get it right -- though the eventual litigation might. :)

Certainly this sort of discussion is nothing new.

Woah, hang on a second... they're patenting the System.Xml namespace? In other words they're trying to patent their version of the nice open DOM API?

Somebody slap them...

It frustrates me how web services are often described as revolutionary, when built on technologies such as UDDI and WDSL which in turn are based on relatively mature technologies such as XML and HTTP.

Indeed, the only maturity in XML is relative. W3C keeps coming up with new standards on how you should define and process XML dialects. The XML standard as a whole is only five years old as of today (see W3C's site).

XML processing standards such as XSL, XSLT, XPath, XQuery, XPointer, XML Schema, SOAP/XML-RPC (getting confused yet? X marks the spot!) are still warm from the oven and they are being revised and replaced already.

Even given all that, XML is not much more than the latest fad for data processing: it is comparable to ASN.1 and SGML from the late 1980s and early 1990s, with its only saving graces being that the standards are free to download and use, yet partially endorsed by Microsoft. There is little indication that XML will prosper after the next big revolution in computing -- indeed, looking at previous "revolutions," a common theme is making it easier to use and/or develop applications on computers. XML so far fails this test. Stacking more and higher layers of data processing standards is not a revolution at all.

Sorry but wired.com does not meet the recommendations at all. Try it yourself

Check the spec dude

As the above link implies, SVG is a W3C standard. It is even supported by modern versions of Flash IIRC.

As the above link implies, SVG is a W3C standard. It is even supported by modern versions of Flash IIRC.

Shame it isnt even vaugley Compliant

Well its a little difficult to validate a website that doesn't mention what DocType it supposedly adheres to. From MSn home page considering the namespace attribute on the html element, and the numerous <br />, that would suggest they are trying to author XHTML. Lets be generous and pretend its XHTML Transitional:

W3C Validation of msn.com: Quite a stackload of errors there. And most certainly not standards compliant HTML. Now if the HTML fails a validation check, there's not much use in validating the CSS. That be asking a lawyer a question while his brain is in a jar of some professors laborators in New York while his body is buried somewhere on the west coast.

From the old article, one of Microsoft's marketing directors should get his facts straight:

"We supported the latest W3C standards when developing the content and services delivered from MSN," ... He added that Microsoft wants users to visit the Web site "regardless of the browser they choose."
But Visse recommended that for the best experience with MSN, customers should use a browser that tightly adheres to the W3C standard.
"If customers choose to use a browser that does not tightly support W3C standards, then they may encounter a less then optimal experience on MSN," he said.

except, that if you ask the W3C validator, it doesn't work!

www.microsoft.com
www.msn.com

Microsoft has a long history of intentionally breaking compatibility with other products to promote their own, as early as (and maybe earlier) the Windows 3.1 -> 3.11 "upgrade" which conveniently broke the diagnostic and repair software PC Tools.

From the old article, one of Microsoft's marketing directors should get his facts straight:

"We supported the latest W3C standards when developing the content and services delivered from MSN," ... He added that Microsoft wants users to visit the Web site "regardless of the browser they choose."
But Visse recommended that for the best experience with MSN, customers should use a browser that tightly adheres to the W3C standard.
"If customers choose to use a browser that does not tightly support W3C standards, then they may encounter a less then optimal experience on MSN," he said.

except, that if you ask the W3C validator, it doesn't work!

www.microsoft.com
www.msn.com

Microsoft has a long history of intentionally breaking compatibility with other products to promote their own, as early as (and maybe earlier) the Windows 3.1 -> 3.11 "upgrade" which conveniently broke the diagnostic and repair software PC Tools.

Uh, it looks very good. It's strict XHTML, and works very well. If you have problems, then you have problems with your browser. Hint: try validating Opera's site and Microsoft's.

Uh, it looks very good. It's strict XHTML, and works very well. If you have problems, then you have problems with your browser. Hint: try validating Opera's site and Microsoft's.

Uh, it looks very good. It's strict XHTML, and works very well. If you have problems, then you have problems with your browser. Hint: try validating Opera's site and Microsoft's.

and the company is not taking out bogus patents to "protect" them.

Yup. And they have a firm stance against software patents too.

The oldest was called Nexus, also simply known as WorldWideWeb.app by Tim Berners-Lee. But OmniWeb is probably the oldest that survived.

My question is, why not use XPath instead of coming up with a chinsy alternate-but-similar notation for selecting nodes in HTML? XPath is a w3 property... why not be consistent? They are trying to retrofit HTML to XML anyway, and IE lets you select nodes in scripts using XPath. (I thought it was part of the DOM standard, but I can't find it - I guess it's an MS extension.)

I guess it would cause some of the CSS syntax to be incompatible with new versions. But that should be solvable by having a well defined way of specifying which version of CSS a CSS file or section is, like you can with javascript. You can specify language="JavaScript1.0" or "Javascript1.2" or whatever to load a JS engine that conforms to that version's specifications (which, unfortunately, conflict in some cases).

I often think that these web standards have all evolved in the wrong order. HTML came before XML and DOM. CSS came before XSL. Bleah.

-If

And we can play with this stuff in Mozilla. Oh happy day. :)

Actually, it's not even CSS3, it looks like CSS2.

The W3 spec has details on the new selectors CSS2 allows.

Nope, it doesn't validate with the w3c's CSS validator. Do we get to start making up random syntax like MSIE now?

According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l and http://www.w3.org/Graphics/SVG/Disclosures, this appears to have been resolved to permit royalty-free use.

If this is true, that's a real victory for the new W3C policy (and for the world in general). Thanks to all. Please let me know if I'm misinterpreting something.

According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l and http://www.w3.org/Graphics/SVG/Disclosures, this appears to have been resolved to permit royalty-free use.

If this is true, that's a real victory for the new W3C policy (and for the world in general). Thanks to all. Please let me know if I'm misinterpreting something.

Nice to see progress being made in this direction...

For thos who do not understand the value of making Svg work on the desktop, it's because you never worked with SVG before.

I've worked all summer long on a job where i had to make a (sacled down and very acurate) map available via web... and it had to be interactively linked to a database...

Now with fixed image this could have been a real pain, but once the map had been transfered from autocad, it was a simple matter: the text in tha map was clickable!

(well, i did have to write a script to build the Svg from a DXF file and it really needs to be cleaned before i post it)

The biggest problem i had to face was the fact that not a single svg viewer passed the W3c Test. The best one i had at the time (The Adobe SVG viewer) was not capable of anchor viewport (ie, using wahtever.svg#viewportdef to automagicaly load the viewport 'viewportdef')

I just wish the format could be more popular... it could the next flash...

There has been quite a lot of discussion of this stuff on various W3C lists, especially over issues as the fact that hex encoding of UTF-8 is case insensitive and URIs are case sensitive...

See the Internationalized Resource Identifiers (IRIs) page for more info.

There has been quite a lot of discussion of this stuff on various W3C lists, especially over issues as the fact that hex encoding of UTF-8 is case insensitive and URIs are case sensitive...

See the Internationalized Resource Identifiers (IRIs) page for more info.

• Next Generation Internet
• Large Scale Networking
• The Xanadu model
• Common HTTP Implementation Problems
• Web Services Architecture Requirements
• etc, etc, etc

• Next Generation Internet
• Large Scale Networking
• The Xanadu model
• Common HTTP Implementation Problems
• Web Services Architecture Requirements
• etc, etc, etc

Scalable Vector Graphics (SVG) is an open-standard alternative to Flash.
it is a W3C recommendation.
there is a partially-implemented SVG native plugin for mozilla.
Adobe has a fully functional SVG plugin.

there is a Call for Participation at the SVG Open 2003 (in canada this july).

sites like homestarrunner.com could really boost SVG acceptance. if anybody out there is looking at homestarrunner.com as a model by which to base their plans for a similar site, please consider SVG!

What you're looking at there is one possible representation of an XML document.

I couldn't agree less. In fact, XML is one possible representation of the abstract hierarchical data structure you described. Furthermore, XML is in fact a text representation. There are many other ways you could represent that data structure (eg: a custom binary format, records in a relational or hierarchical database, a object serialised to a binary stream etc) but none of them are XML.

The W3C themselves say that "XML is text" and then go on to point out that advantages of being a text format include:

• you can look at data without needing the program that produced it
• you can read it with you favourite text editor
• it's easier for developers to debug

They also say: "Like HTML, XML files are text files that people shouldn't have to read, but may when the need arises".

In parallel with the development of XML, our notion of the definition of 'text' has also moved forward. Through the adoption of standards like Unicode and bridging facilities like encoding declarations, we have moved past 7-bit ASCII as being the one true text.

To claim that an XML file is not "editable in emacs (or vi), grep-able, diff-able or understandable to the naked eye" is demonstrably untrue. You'll obviously need a text editor that understands whichever encoding the file uses (both emacs and vim fit that bill) but a text editor is a perfectly servicable tool for viewing and editing XML (obviously not the best tool in many cases, but acceptable nontheless)

Regarding:

This document specifies HTTP extensions that bridge the current location-based Web with the Content-Addressable Web. -- HTTP Extensions for a Content-Addressable Web

The World Wide Web is "the universe of network-accessible information", i.e. anything with a URI, including URIs that are not tied to a particular hostname.

The Web already includes non-location-based URIs like mid: (for referring to message-ids), and urn:sha1: for referring to a specific set of bits by their checksum.

This proposal seems like a decent way of bridging HTTP-space with URN-space, but please remember that the Web is more than just HTTP. (see also: URIs, URLs, and URNs)

Anyway, it seems to me that sites that tend to suffer from slashdotting are:

1. those that use dynamically-generated pages for what is basically static content: this problem can be fixed by sites making sure their content is cacheable, and further deployment of HTTP caches. (I'm not convinced a p2p-style solution is the solution here.)

2. those with large bandwidth needs (kernel images, linux distribution .iso's, multimedia): as p2p software becomes more mature and widely deployed, everyone will have a urn:sha1: resolver on their desktop (pointing to their p2p software of choice), then whenever a new kernel is announced, the announcement can say:

   Linux kernel version 2.4.20 has been released. It is available from:
   
   Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2 .4.20.gz
   a.k.a. urn:sha1:OWXEOVAK2YJW3G6XSULXDWFCNWTX7B2K
   Full source: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2 .4.20.tar.gz
   a.k.a. urn:sha1:PPWXYMA32YNDNO35UD3IQTCWBVBYK5DC

   and people can just fetch the files using urn:sha1 URIs instead of everyone hitting the same set of mirrors. (gtk-gnutella already supports searching on urn:sha1: URIs)

Regarding:

This document specifies HTTP extensions that bridge the current location-based Web with the Content-Addressable Web. -- HTTP Extensions for a Content-Addressable Web

The World Wide Web is "the universe of network-accessible information", i.e. anything with a URI, including URIs that are not tied to a particular hostname.

The Web already includes non-location-based URIs like mid: (for referring to message-ids), and urn:sha1: for referring to a specific set of bits by their checksum.

This proposal seems like a decent way of bridging HTTP-space with URN-space, but please remember that the Web is more than just HTTP. (see also: URIs, URLs, and URNs)

Anyway, it seems to me that sites that tend to suffer from slashdotting are:

1. those that use dynamically-generated pages for what is basically static content: this problem can be fixed by sites making sure their content is cacheable, and further deployment of HTTP caches. (I'm not convinced a p2p-style solution is the solution here.)

2. those with large bandwidth needs (kernel images, linux distribution .iso's, multimedia): as p2p software becomes more mature and widely deployed, everyone will have a urn:sha1: resolver on their desktop (pointing to their p2p software of choice), then whenever a new kernel is announced, the announcement can say:

   Linux kernel version 2.4.20 has been released. It is available from:
   
   Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2 .4.20.gz
   a.k.a. urn:sha1:OWXEOVAK2YJW3G6XSULXDWFCNWTX7B2K
   Full source: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2 .4.20.tar.gz
   a.k.a. urn:sha1:PPWXYMA32YNDNO35UD3IQTCWBVBYK5DC

   and people can just fetch the files using urn:sha1 URIs instead of everyone hitting the same set of mirrors. (gtk-gnutella already supports searching on urn:sha1: URIs)

Wow there are so many errors, it looks like Slashdot.

I sent this email to museumtour.com 2 days ago. Hopefully, this helps them out.

I have seen the ridiculous claims by SBC concerning your website and their patents. So, I thought i might attempt to be a little help in this situation and do a little online searching for previous art. http://lists.w3.org/Archives/Public/www-html/1995S ep/0034.html As you can see, that email is from September of 1995, almost a full YEAR before that patent was filed. It appears that the patent SBC filed was on the very reason for the invention of frames in the first place!

In particular I would like to refer to the following in that September 1995 email: NAME="window_name" The NAME attribute is used to assign a name to a frame so it can be targeted by links in other documents (These are usually from other frames in the same document.) The NAME attribute is optional; by default all windows are unnamed. Therefore, a frame could remain static while referencing other frames with each click in the original frame.

Also, you might check out this url: http://www.focazio.com/web95/images/cnn.gif

This is a screenshot of cnn.com in 1995. I'm sure you'll notice the navigation icons at the top.

Also, there is this link: http://www.ac603.dial.pipex.com/webinov.htm#Intro

As you see, it's from December 1995 and SPECIFICALLY talks about using frames for navigation.

Fred Sotherland of C|Net gave an overview of how the C|Net television network is using the web to integrate TV with the Internet. He also gave some rules which they apply to make sure that pages are usable.

* *No page with more than 20k graphics * *All pages have 256 colour graphics * *Making use of Netscape 2.0 frames to put content and navigation side by side. * *Your only limitation is your Imagination (an the available bandwidth)

Again, this link is from November 1995: http://www.i-m.com/November-1-7-1995/0018.html

If you read that, you see the following: - If you have an image (a button bar for example) that is 80 pixels high and 400 pixels wide, DON'T make a Frame 80 x 400. As with everything else, allow a buffer. The scroll bars (or the blank space that makes them up) runs 20-25 pixels. In addition to that Netscape does appear to add a little more in the gutter area. An 80 x 400 image should be in a 110-120 x 430 frame at the least. - More of a good thing, isn't better. Having a fixed portion of the interface for the navigation bar is a good thing. However, having 4 frames isn't.

As you can see from that, not only does it mention a navigation bar, but it also mentions a BUTTON BAR..like what you have on your webpage. That is from the year BEFORE SBC's patent.

If there is any doubt to that, check this link: http://english.ttu.edu/kairos/1.1/guide.html The pictures are from Spring 1996 when the patent was filed, but they're using the features from Netscape 2.0.

http://semanticstudios.com/publications/web_archit ect/frames.html This is a PERFECT PERFECT PERFECT example of prior art. It is published 2 months before the patent application and describes websites with the EXACT features the patent was filed on.

One more, from netscape itself discussing netscape 2.0: http://wp.netscape.com/navigator/v2.0/frames.html

Netscape 2.0 was released in February of 1996, as you can see from this link: http://scout.wisc.edu/addserv/NH/96-02/96-02-05/00 31.html

That is all I have time for right now, I hope you fight this and don't give in. There is clearly prior art and it seems SBC just filed a patent on something that was already in heavy use at the time of the filing. Now, they want to harass small companies almost 7 years later. They don't go after the big companies because they know their claims are fraudulent. But, I think if you can show them YOU know beyond the shadow of a doubt that their claims are ridiculous, they might look elsewhere for a sitting duck.

Hare Krishna!

http://lists.w3.org/Archives/Public/www-html/1996J an/0110.html

This email, sent to the html list at w3.org on Jan 12, 1996, describes an existing feature in Netscape identical to SBC's claim.


I remember reading an article about a hypertext browser which supports
connected-frames does something like the following. You open an URL and
select SplitScreen from a menu. Now both frames of the screen is showing
the same URL. Then you do some UI maneuver to connect the ``output port''
of the first frame to the ``input port'' of the second frame. You then
click on the first anchor of the first frame and the second frame changes
accordingly. What FRAMES in Netscape does seems to be a short cut for
these steps.

In the abstract for that page, it says:

Frames extend the layout flexibility of HTML to allow finer control over content reload. This enables the designer to freeze content in place and target results of actions into specific regions of the screen.

This is exactly what frames were designed to do. Besides the prior art, the idea is so obvious it doesn't deserve a patent, even if no one had come up with it.

Here is the text of the e-mail I sent to museumtour.com after uncovering what I think may be prior art, in only a few minutes poking around on the web:

Sir,

I have been appalled by the acceptance of over-broad patents by the USPTO for some time, and was similarly appalled to see the abuse of a patent on Frames-based browsing used to threaten legal action against your site. Although I am not a lawyer, I believe that I may have found some invalidating prior art. [Please insert standard not-a-lawyer disclaimers here.]

As far as I can tell, the patent covers the existence of links in one frame that affect the display of information in another. This technique was described and published in the original documentation on frames, which you can see on the Netscape website here:

http://home.netscape.com/assist/net_sites/frames.h tml

This includes the text:

These properties offer new possibilities:

1. Elements that the user should always see, such as control bars, copyright notices, and title graphics can be placed in a static, individual frame. As the user navigates the site in "live" frames, the static frame's contents remain fixed, even though adjoining frames redraw.

2. Table of contents are more functional. One frame can contain TOC links that, when clicked, display results in an adjoining frame.

3. Frames side-by-side design allows queries to be posed and answered on the same page, with one frame holding the query form, and the other presenting the results.

Point 2 appears to describe the technique patented, and therefore constitutes prior art if published before 17 May 1996.

This documentation does not itself have a date, and has not been archived by the Wayback Machine (http://www.archive.org), but appears to have been in existence for some time prior to the patent application date. The evidence for this comes in a reference from a post to the HTML mailing list in January 1996:

http://lists.w3.org/Archives/Public/www-html/1996J an/0110.html

It should be possible to check with Netscape to determine the date of publication of this web page.

I hope that this is of some use.

Netscape proposed the concept of frames to the W3C in September of 1995.

This is the best comment I've seen so far, but it doesn't really prove prior art. The page you refer to is dated 1999. As with many innovations, the presence of an enabling mechanism does not necessarily indicate prior art.

Can you prove that frames were intended for use as contemplated by the patent, i.e. a consistent user interface across a document or site? Not from that article. Remember too that not only frames are at issue here -- a navigation bar using tables or divisions would appear to be covered by the patent as well.

While it is blatently obvious with hindsight that frames can be used in this manner, some Googling around will show that a huge amount of web design material at the time references a document called "Ameritech Web Page User Interface Standards and Design Guidelines" by Detweiler, M.C. and Omanson, R.C. (1996), on the matter of creating a consistent user interface by using frames. If that doesn't ring a bell, Ameritech was the original holder of the patent, and recently acquired by SBC.

Reading the patent provides some more insight too: they contemplate a document with embedded codes indicating document sections, that conforms to a predefined structure. Read this way, the patent does not partain to HMTL frames, because HTML is a hypertext linked collection of documents, not a single document. A navbar or frame moving the view to named references within a single document, however, would clearly violate the patent.

So is the patent valid? Well, that involves proving prior art; not just that frames existed, but that they were used for the purpose of navigation, both in a single document and between documents. Any evidence of tables to do the same thing would also be useful. Also crutial is having an incontestible source -- printed information is best, a reputable online news source or journal is the next best thing.

w3.org records Edelstein's Sep 1995 proposal to include frames in the HTML specification, but the example page he sites is no longer available.

The Netscape Navigator 2.0 announcement contains "Frames, a new page presentation capability that enables the display of multiple, independently scrollable panels on a single screen, each with its own distinct Internet address. They also enable a region of the screen to be frozen in place as the user scrolls through information on a page". Tantalising, but it doesn't mention using the frozen region for navigation.

Most promising are the Mozilla 2.0 release notes. Two of the example links are broken, while third doesn't work in my browser, although the pages appear to be there. It clearly demonstrates the use of a navigation frame to select different pages in a site, and view them in a "dynamic" frame. That said, the navigation frame itself is not entirely static (it scrolls, but does not change), and there is no navigation inside a single document from the frame.

There is a lot of effort required to find proper evidence of prior art that will hold up in court. The Wayback Machine would provide great evidence, if only we can find it.

If we look at HTML the FRAMESET/FRAME construct has become part of the HTML 4.0 specification in 1998. Officially both HTML 2.0 ('95) and HTML 3.2 ('97) did not support frames. I think however this has been done because both IE and Netscape did support frames for a while at that time.

It's obvious that similar concepts and implementations of what they patented have been done before...

If we look at HTML the FRAMESET/FRAME construct has become part of the HTML 4.0 specification in 1998. Officially both HTML 2.0 ('95) and HTML 3.2 ('97) did not support frames. I think however this has been done because both IE and Netscape did support frames for a while at that time.

It's obvious that similar concepts and implementations of what they patented have been done before...

If we look at HTML the FRAMESET/FRAME construct has become part of the HTML 4.0 specification in 1998. Officially both HTML 2.0 ('95) and HTML 3.2 ('97) did not support frames. I think however this has been done because both IE and Netscape did support frames for a while at that time.

It's obvious that similar concepts and implementations of what they patented have been done before...

You can find the rules for making a Schema at the W3C XML Schema Page. The wording of the link is beautiful: "An XML Schema schema document for XML Schema schema documents."

If you really want a challenge, try reading the schema schema. Packed full of circular definitions and elements defined in terms of themselves, it's sure to make your head spin!

You can find the rules for making a Schema at the W3C XML Schema Page. The wording of the link is beautiful: "An XML Schema schema document for XML Schema schema documents."

If you really want a challenge, try reading the schema schema. Packed full of circular definitions and elements defined in terms of themselves, it's sure to make your head spin!