Lists Home |
Date Index |
Bullard, Claude L (Len) wrote:
>Then this shouldn't be about XHTML. It should be about
>a better mouse trap. First, just as mental fodder:
>Alan Kay notes that we still have a lot of room to innovate.
>1. This should be about a better web browser, not a Spy Vs Spy
>among committee members.
>2. I do not accept that standardization ALWAYS follows innovation.
>The fear of committee-driven innovation is not justified by the
>model, but by the competence of the members in all of the dimensions
>in which they must negotiate. It can work but it doesn't always
>work. Before we abandon it to 'open to implement but proprietary
>specifications' let me note that acceptance of standards as a way
>of doing business has benefited the growth of the web and the
>3. But it isn't necessary to grandfather a lot of standards
>and specifications that don't play together. A leap forward,
>a real innovation, might be something altogether different
>than what we have, and it might be painful for the content
>owners. It might be simpler but it has to be consistent.
>4. It might take time. That's ok.
>>From a perhaps naive perspective, the topical issue comes down to this:
>if a resource returned by a URI has <?xml in the document, the
>rules for processing it and returning errors should be clear,
>simple, and enforced by the browser. If it doesn't have that,
>then it is a laissez-faire situation which is what we have now.
>I'm ok with that. If the intent of the author is not made
>clear, then the rules are up to the developer, but we have
>gone on too long letting the developer set all the rules.
>As we begin to see more and more portal systems that rely
>on web services, the reliability of this approach will fall down
>service by service which is why I sent that 3.1 mb screen shot
>to the list. A dumb move (should have compressed it) but it
can't say my 2400 baud line at my farm where i was at the time was too
impressed either. perhaps a url to the image would have been better :)
>is a simple example of what happens when combinations of filtering
>semantically or otherwise combine with non-local control of a
>service and globally distributed services. I don't think
>building web services for a browser with HTML is a good idea.
>I think racing ahead to implement semantic web systems
>without working out the problems of reliability are a
>recipe for god-awful embarrassment in the minor cases
>and election-stuttering disasters in the major ones.
>This comes down to a competition among companies who
>accept the challenge of improving on the status quo and
>accept the risks of a long term marketing campaign to
>get a better technology fielded. It is time to drop
>the MicroPhobia, drop the 'we have this specification;
>let's form a consortium' game, and work the problem of
>building a better and more reliable web authoring and
>delivery system. I don't know what that will be.
>That's why it is innovation and not just reinvention of
>ideas proposed ten years ago.
>From: Joshua Allen [mailto:email@example.com]
>>>XHTML vastly simplifies machine processing for all sorts of
>>Yep, this is the only concrete benefit of XHTML I've seen. It makes it
>>easier for people to screen scrape your site. I find this to be a very
>>dubious benefit at best.
>Yeah, it's shows the narcissism of most developers. "Please rewrite
>your page in some buzzword-compliant gobbledy-gook subset of XML that is
>less reliable and harder to test than what you were already doing, and
>then I can theoretically write a screenscraper".
>For people who really want repurposable data; we already have capability
>to do XML+XSLT+CSS. My RSS feed and OPML feed are both pure XML (no
>XHTML crap) and render nicely in IE and Mozilla. XHTML is a
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>To subscribe or unsubscribe from this list use the subscription
tel;cell:+61 411 287 530