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

Re: What should TrAX look like? (Was: Re: Articleon

  • To: Michael Kay <mike@s...>
  • Subject: Re: What should TrAX look like? (Was: Re: Articleon JAXP 1.3 "Fast and Easy XML Processing")
  • From: Elliotte Harold <elharo@m...>
  • Date: Thu, 17 Feb 2005 13:40:12 -0500
  • Cc: 'XML Developers List' <xml-dev@l...>
  • In-reply-to: <E1D1lMG-0002Gf-00@u...>
  • References: <E1D1lMG-0002Gf-00@u...>
  • User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217

Re:  What should TrAX look like? (Was: Re:  Articleon
Michael Kay wrote:


> I'm disappointed to see my defence of the design dismissed in that kind of
> language. I didn't claim it was perfect but I did say that I thought it was
> better than the alternatives, and no-one has yet shown me an alternative
> that is demonstrably better.

It's been known for about 50 years that scientific theories aren't 
necessarily abandoned just because it's easy to prove they're 
demonstrably wrong. Scientists hold onto theories they know can't 
possibly be correct until someone comes along with a better one.

The Source interface is demonstrably wrong. It's only marginally 
preferable to passing in Object. I was taught long ago that anytime you 
see code doing something like this:

if (o instanceof A) {
   A a = (A) o;
   doSomethingWithA(a);
}
else if (o instanceof B) {
   B b = (B) o;
   doSomethingWithB(b);
}
else if (o instanceof C) {
   C c = (C) o;
   doSomethingWithC(c);
}

then you've missed out on an opportunity for polymorphism. Sometimes 
this sort of instanceof stack is necessary, especially if you don't own 
or control the classes A, B, and C. However sometimes you can do better. 
Is this one of those time? I think it might be, and it's worth exploring 
if we can get something better.

The big impedance mismatch is with streaming and tree models, but we can 
convert from one to the other. My main question is whether implementers 
of XSLT processors, XPath engines, and Validators would rather receive 
the data as a tree model or as a stream of events.

I'm also not sure how we map back from whatever interface we do create 
to the actual objects; not necessary for XSLT, very necessary for XPath.

It's not a slam dunk. There are real questions here, and the whole 
enterprise might not work. Nonetheless, I don;t think it';s worth 
rejecting out of hand. It's not as if the current solution is a paragon 
of object oriented purity. It certainly doesn't make it easy to adapt 
tools to new object models.

-- 
Elliotte Rusty Harold  elharo@m...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.