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 should TrAX look like? (Was: Re: [xml-dev] Articleon

[ Lists Home | Date Index | Thread Index ]

Dare Obasanjo wrote:
>>-----Original Message-----
>>From: Paul R Brown [mailto:prb@fivesight.com] 
>>Sent: Thursday, February 17, 2005 11:14 AM
>>To: 'XML Developers List'
>>Cc: 'Elliotte Harold'; Michael Kay
>>Subject: Re: [xml-dev] What should TrAX look like? (Was: Re: 
>>[xml-dev] 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.



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

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