[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
Dare Obasanjo wrote: >>-----Original Message----- >>From: Paul R Brown [mailto:prb@f...] >>Sent: Thursday, February 17, 2005 11:14 AM >>To: 'XML Developers List' >>Cc: 'Elliotte Harold'; Michael Kay >>Subject: Re: What should TrAX look like? (Was: Re: >> Article on JAXP 1.3 "Fast and Easy XML Processing") >> >> >>I also go so far as to say that the discussion is a bit misdirected: >>the apparently poor encapsulation of Source is more of a >>symptom of the fact that TrAX transformers (e.g., XSLT >>processors but potentially STX or XQuery or...?) need to be >>able to implement their underlying model however they so >>choose. Source is little more than a marker interface, and >>the thing that makes sense (at least to me) is to have >>off-the-beaten-path Source implementations (e.g., for a pull >>parser) exhibit enough polymorphism (implement SAXSource, >>DOMSource, etc.) to make them useful and reasonably portable >>for consumption by different Transformer implementations. > > > Marker interface is a synonym for design flaw. A marker interface is just that - a marker. The design flaw happens when you leave it there and don't fill it out. Casting is a way to get answers on-demand, parametric polymorphism is way to supply answers for the questions you knew about upfront. I still think there's a need here for an object that can answer questions about what's being transformed. The exception to that is if you know that there are precious few questions - then polymorphism works a treat - I don't get that sense in this case. cheers Bill
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|