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]
