[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What is the rule for parsing XML in a namespace inside HTM

• To: "Bullard, Claude L (Len)" <len.bullard@i...>
• Subject: Re: What is the rule for parsing XML in a namespace inside HTML?
• From: Rick Marshall <rjm@z...>
• Date: Wed, 14 Jul 2004 09:05:16 +1000
• Cc: XML Developers List <xml-dev@l...>
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE03F9F9EC@h...>
• Organization: Zenucom Pty Ltd
• References: <15725CF6AFE2F34DB8A5B4770B7334EE03F9F9EC@h...>
• User-agent: Mozilla Thunderbird 0.6 (X11/20040502)

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:
>
>http://www.fortune.com/fortune/fastforward/0,15704,661671,00.html
>
>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 
>industry.
>
>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.
>
>len
>
>
>From: Joshua Allen [mailto:joshuaa@m...]
>
>  
>
>>>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
>Frankenstein.
>
>-----------------------------------------------------------------
>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
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>  
>

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@z...
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard

• References:
  • RE: What is the rule for parsing XML in a namespace inside HTML?
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: Re: Edi complexity, does ebxml really reduce it?
• Next by Date: Re: What is the rule for parsing XML in a namespace inside HTML?
• Previous by thread: RE: What is the rule for parsing XML in a namespace inside HTML?
• Next by thread: RE: What is the rule for parsing XML in a namespace inside HTML?
• Index(es):
  • Date
  • Thread