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] Streaming XML (WAS: More on taming SAX (was Re: [xml-dev]

[ Lists Home | Date Index | Thread Index ]

Hi.

>>  I'm sure I can win a "productivity" bake-off using
>> available Python/XML tools any day against any XQuery machine.  I can
>> say the same for most of my colleagues.

> I love that idea .   Iit would be fun and instructive to see a bakeoff
> ... snip ...

> The trouble is, I'll bet that the results would depend on the problems
> chosen more than the tool used to build the solution

And even worse... give me a problem I'm familiar with and I'll be better  
able to solve it no matter what technology you pair me up with (within  
reason).


---->N

  -- There are
> plenty of problems that C-Omega could solve in a few lines that XSLT
> would bog down on even in the hands of a master, and vice versa. I
> wouldn't be surprised at all if Python or XQuery were the best overal
> with some fair and balanced distribution of problems, but that would
> be meaningless to people who spend most of their lives with documents
> and love XSLT, or spend their lives with straightforward schema-valid
> data and can exploit the kinds of things that  C-Omega does at compile
> time.
>
> Another problem is that there are at least two target audiences here
> -- the people who learn and build tools for their own use, and those
> who build tools for ordinary mortals to use.  The question in my mind
> is whether the the winner of a bakeoff among XML ubergeeks would
> predict the winner of a bakeoff among ordinary mortals with, say, a
> week's training on the tool of choice?  That's a contest I would
> REALLY like to see!
>
> Sigh, yet another problem is the short-run vs long-run issue:  In the
> long run we can expect with some confidence that the "declare what the
> answer looks like and let the tool build the code" approach will work
> best, but I doubt very much if any existing tools can do that.  On my
> better days, I can see the point that Dana alluded to  that
> short-term optimization keeps the state of the art from advancing to
> meet the full potential of the more declarative approaches.  Still, in
> the long run we are all dead, and our careers will be dead much sooner
> if we don't solve real customer problems in a reasonable timeframe!
>
> -----------------------------------------------------------------
> 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>
>



-- 


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.




 

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

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