OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] What is the rule for parsing XML in a namespace inside HTM

[ Lists Home | Date Index | Thread Index ]

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 
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:joshuaa@microsoft.com]

> > XHTML vastly simplifies machine processing for all sorts of
> > purposes.
> 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS