Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What should TrAX look like? (Was: Re: Article on
 Agreed - Source itself perhaps will evolve very slowly - but you point out can have interfaces extending Source that become the common denominator over time. Oops my bad - yes you are right - I didn't mean to say what the models need but did end up saying that:-(. It would be useful to come up with common abstractions as you mention - But here again the key to me is I like starting with things underspecified and then build more common and more useful abstractions. if Source had defined a heavy interface (which was not agonistic of the models, etc) then that to me would have been even worse. Surely it underspecifies in my mind and defines a very low common denominator - but this allows us to build on top of it better layers or abstraction. Surely DOMSource would not have been acceptable for other models. Till we find the right tradeoffs and an abstraction that is acceptable to all - it is best not to dictate - which of course means till then you have to know whether it is a DOMSource, JDOMSource, etc - but that to me is better than saying I will go with DOMSource and then everybody else contort themselves to fit what I specify. prakash --- Elliotte Harold <elharo@m...> wrote: > Prakash Yamuna wrote: > > > > This becomes very useful from an evolution > > perspective. The reason it is underspecified is a > lot > > of models have disparate needs and there has been > no > > common agreement on how they can expose it. > > This is backwards. The question is not what the > models need. the > question is what the engines consuming the source > need from the models. > If this can be standardized, then the models can > provide it. For XPath > and XSLT what the engines need is pretty well > defined. For other > uses--XPath 2, schema validators, XQuery > engines--perhaps it's not so > clear, but maybe we could come up with something. > > > But over time as things mature and our > understanding > > increases - the disparate models, implementations > can > > come to an understanding on what their needs would > be > > - at that point Source can evolve further and > there > > can be more meat to its interface. > > > > But because of the fact all the models decided to > > adhere to Source - they will support this much > heavier > > interface. > > That's very unlikely to happen. Adding methods to an > interface breaks > all existing implementations of the interface, and > this has something > Sun has been singularly unwilling to do in the past. > If there is a new > interface, it might be a subclass of Source, but > supporting it will be > far from automatic. > > -- > 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 > > ----------------------------------------------------------------- > 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> > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
|
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
|
|||||||||
