Re: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")

[Prakash Yamuna <techpy@yahoo.com>]

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@metalab.unc.edu> 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@metalab.unc.edu
> 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