> -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 30, 2003 3:48 PM > To: Ant Developers List > Subject: Re: XML Namespace avoids collision between xml vocabularies was > RE: a comment about xml namespace > > > Jim Fuller wrote: > >>From: Steve Loughran [mailto:[EMAIL PROTECTED] > >>Sent: 29 December 2003 17:59 > >>Subject: Re: XML Namespace avoids collision between xml vocabularies > > > > was > > > >>RE: a comment about xml namespace > >>If you are interested in this kind of thing, point your browser at > >>http://1060.org and d/l a build of NetKernel -preferably 2.1 when it > >>ships shortly. This is definitely a generic XML processor engine which > >>does plenty much magic, like (in v2.1) autobinding a database select > > > > to > > > >>an XML document for later xformation. > > > > > > [Jim Fuller] interesting, will have a look... > > > > yes, worth a play. > > On an ant topic, they have an alternate dependency model, one not that > suited to a generic build process, but ideal for an XML engine. > > Here is where we are today: > > Ant: leave everything to the tasks > Make: declare everything > msbuild: declare everything (I think) > > NetKernel code consists of a set of instructions, all with a standard > syntax for operands and results, with different XML in the operand > field. The engine takes the operands and concatenates that with the > operator and constructs a URI that describes the operation. > > e.g. here is me applying xtidy to some generated code: > <instr> > <type>XHTMLTidy</type> > <operand>this:response</operand> > <operator> > <xpath>/results/row/details</xpath> > </operator> > <target>var:tidied_details</target> > </instr> > > The cool thing is that the contents of every operation are cached; > stored in the cache relative to the URI in. Which means that next time > the command is executed, if the inputs havent changed, the cached result > is returned instead. > > So the SQL query used to generate the XML to tidy up is just stuck in in > front, with the runtime handling all the details of pooling, database to > xml binding and choosing when to run stuff: > <instr> > <type>stm</type> > <operand><sql/></operand> > <operator> > <stm:group xmlns:stm="http://1060.org/stm";> > <stm:set xpath="/sql"> > SELECT * > from col > where col.colID=<stm:param > xpath="substring-after(/uri , ':')"/> > ; > </stm:set> > </stm:group> > </operator> > <param>var:col</param> > <target>var:sql</target> > </instr> > <instr> > <type>Col</type> > <operand>var:sql</operand> > <operator> > <method>sqlQuery</method> > </operator> > <target>this:response</target> > </instr> > > Of course, there is a problem: what if another operation has side > effects, like a SQL update. That is where you need to create pseudo > dependencies that sequences say they depend on; other things can touch > these to mark them out of date. > > The nice thing about this model is that there is a single engine > managing caching across all the threads working away, and it caches the > intermediate stuff, with various controls to choose when stuff expires > (different stuff can be marked as more important, so a big db query is > cached above some little xslt operation). > > Like I said, I dont see it applying to Ant, but it shows an alternate > world view in the XML-workflow-language space, at least for a workflow > focused on a server handling requests, doing things and sending the > results back. > > > > > > [Jim Fuller] uhhh, I just want an xml document to be used by multiple > > processors, not have Ant *be* the generic processor. I always assume > > that data lives longer then the applications that generate or manipulate > > them....oh well as I said, I will leave this thread asis, for the time > > being. I need to spend a few days looking at Ant internals, before I > > comment any further. > > Ok, that is all right then. > > Maybe we should have > > 1. an <xmlcomment> type; takes generic XML. > > 2. an <xmldata> type, that takes generic XML with an ID that you can > refer to later. So any task that wants to use XML inline, can share the > data. > > Thoughts? And yes, I know (1) and (2) are nearly identical. But (1) > could discard all internal sax events. > > -steve > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
